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(57) Abstract: Sysiem and method for enabling application server request failover. For each application server request to t>e per- 
formed by a client computer, a requesting thread may be operable to utilize a custom wiie-level communication protoccrf. Request 
^ failure detection mechanisms may be built into the custom wire-level communication protocol so that a requesting iluead detects a 
^^ failed request much sooner than if the thread utilized a standard communication protocol and relied on the client computer opeiatins 
*^ system for mKification of failed requests. Afler sending a request to an application server, a requesting thread may be operable to 
2 'sleep* and then periodically wake up to poll the application server computer to determine whether the request has failed: If the le- 
questing thread receives a response' from the application server computer indicating that the recpiest is not currently being proces s ed, 
then the requesting thread may re*send the requesL Receiving no response to the poU message may indicate that the application server 
^ computer is offline. e.g.. due to a failure. The requesting thread may redirect the request to another application server computer if 
^ necessary. 
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TITLE: SYSTEM AND METHOD FOR ENABLING APPLICATION SERVER REQUEST FAILOVER 



BACKGROUND OF THE INVENTIOW 

1. Field of the Inventian 

The present inveDtion relates to the field of application servers, and more particularly to a system and 
method for enabling application server request failovcr. 

2. Description of the Related Art 

The Held of application servers has recently become one of the fastest-growing and most inqMntant fields 
in the computing industry. As web applications and other distributed applications have evolved into large-scale 
appHcations that demand more sophisticated computing services, specialized aj^lication servers have become 
necessary, in order to provide a platfomi supporting these large-scale applications. Applicaticins that run on 
application servers are generally constracted according to an n-ticr architecture, in wbkk presentation, business 
logic, and data access layers are kept separate. The application scnrcr space is sometimes referred to as. 
•^ddlcwarc'*, since application servers arc often responsible for deploying and running Ac business logic layer 
and for interacting with and integrating various entezprise-wide resources, such as web servers^ da t a b ases, and 
legacy systems. 

Application servers offer significant advantages over previous a^^proaclies to implemeutug web. 
applications, such as using common gateway interface (CGI) scripts or programs. Figure 1 iOusuates a typial 
architecture for a web appHcatipn utilizing CGI scxipts or programs. The client computer running a web browser 
may reference a CGI program on the web server, e.g., by referciunng a URL such as 'iitlp://servcr.domainxom^(^i* 
bin/myprogram.pr. Generally, the CGI program runs on die web server itself, possibly accessing a database, e.g. 
in cxrder to dynamically generate HTML content, and the web server returns the output of the program to wdi 
browser. One drawback to this approach is that the web senrer may start a new process each time a CGI program or 
script is invoked, which can result in a high processing overhead, impose a limit on die munlMer of CGI programs 
that can run at a given time, and slow down the perfomiance of the web server. In costRBS^ ^iplication servcn 
typically provide a means for enabling programs or program components that are referenced via a URL to lun on a 
separate con^uter from the web server and to persist between client invocations. 

Another common drawback of previotis web application design models, such as the use ofCGI programs, 
is related to data access. For example, if a CGI program needs to access a database, the program typically opens a 
database connection and dien closes the connection once it is done. Since opening and closing d atabase 
connections are expensive operations, these operations may further decrease the performance of the web server 
each time a CGI program runs. In contrast, application servers typicaOy provide a means to pool database 
connections, thus eliminating or reducing the need to constantly open/close database connections. Also, data access 
in CGI programs is generally coded at a relatively low level, e.g., using' a specific dialect of SQL to access a 
specific type of database. Thus, portions of the application may need to be recoded if the database is replaced with 
a new type of database. Application servers, on the other hand, may provide a database service for applications to 
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utiloe as an interface be«.een *e application and the daubase. which can sexve .0 abstract the appKcatioa from . 

particular type of database. _ 

Applicadon servers may also provide nuory other types of application services or may provide standanl 
reusable components for tasks that web applications commonly need to perfonn. Application servers oltai 
incorporate these services and components into an integrated development envrromnent specialized for creat-g 
web applications. 1^ integrated development environment may leverage various standard software component 
models, such as the Common Object Request Broker Architecture (CORBA). the (Distributed) Component Object 
Model (COM/DCOM). Entoprise JavaBeans- (EJB). etc, or the integrated development environment m<nr 
provide its own softv^are component model or may extend standard component models in vanous way. 

The following list is a paitiallist of the types of application services or appUcatioD components tfast 

application servers may provide. By leveraging these types of integrated. pre.b«flt services and 

application devdopers may realize a significant r^hrction in appHca^ 

dLop a more robust. bug.ftee application. Application servers fh«. different vendors difldr. of course. « *^ 
types of services they provide; thus, the foDowing list is exemplary only. 

. AS noted above, application servers may provide data access services for accessing various type, of da«ab««. 
d„o»Bh direcdy supporting proprietary databases, such as S^^ 
^dized interfaces, such as ODBC JDBC. etc. Also, as noted above, appiicalio. server, imiy enaWe 

database connection pooling or cachin g , 

. Application server, may also provide service, for accessing network direo^ 
support the standard LightweightDirectoiy Accen Protocol (LDAF). 

. Application servers may also provide applicadon security services or components. ^»AmiS»6onu^ 
r^y be considered at different levels, such as: dient-to-server communication, application-levd prrvilege.. 
database access, directory service access, etc AppBction server security-related services/con,ponen.. msy 
h^tode support for performing user aud.entica.ion. performing data encryption. 

pr^ocols such as Secure Sockets Layer (SSLX utilizing security certifrcates. programming user .cce« rrgh-. 
integrating with operating system security, etc. 

. Apphcation servers may also provide services enabling a web appUcation .0 easily maintdn ns« 

irrformation during a user session or across user sessions. Performing state and session n^agement « 
especiany important for applications diatbave complex, multi-step nansadions. 

. Application servers may also support caching Ure results of applicadon logic execution or caching the resuhs of 
web page/component output, so that for appropriate subsequent requests, the results may be re^ 
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. Applicadon sefv«s may also support result streaming, such as dynamically streaming HTIT outpttt. whidi 
may be especiaUy usefiil for large result sett involving lengdiy queries. A related service may enable an 
appUcation to easily display a large result set by breaking the resuh down into smaUer groups and 
displaying these groiq>s to die tiser one at a time. 

. Many web applications need to perform various types of searching or indexing operations. Application serveis 
may also provide application sendees for indexing or searching various types of documents, databases, etc. 

> As noted above, many web applications may perfoim various types complex, muhi-stqi tiansactiais. 
Application servers may also provide st^iait for managing these application transactions. For example, dus 
support may be provided via a software component model supported by die application server, such as die 
Biteiprise JavaBeans"' conqmnent model, or via integration widi diird-paity transaction process monitois. etc 

• It is often desirable to enable web applications to perform certain operations independendy, as opposed to in 
response to a user request For example, it may be desirable for an application to automatically send a 
newsletter to users via emaO at regularly scheduled imervals. Application serveis may sappatt die cieatiai and 
scheduling of events to peifonn various types of opexatioiis. 

• Many types of web applications need to peifoim e-commerce transactions, such as credit card transactions, 
financial data exchange, etc, AppKcation serveis may provide services for performing various types of e- 
eommen* transactions or may provide an integrated diird-paity e-<ommerce package for appto^ 



• Web awKcations often need to utilrte various types of standard network appUation services, such as dn emafl 
service, FTP service, etc AppKcation servers may provide diese types of services and may enable appUcatioaa 

25 to easily integrate widi the services. 

• W«* applications often need to log various conditions or eventt. AppKcation serveis may provide an 
integrated logging service for web applications to use. 

30 Judging by die exwnplary list above of conq»uting services diat appUcation serveis may provide for wd» 

appKcations, it is apparent duit appUcation serveis may integrate a diverse range of services, where diese services 
may interact widimany different types of servers, systems, or odier services. For example, an appBeation server 
may act as a platform hub connecting web servers, daubase servos/services, e-commeree servers/services, legacy 
systems, or any of various odier types of systems or services. A key benefit of many appUcation servers is that diey 

35 not only provide diis service/system integration, but typicaUy also provide centraKzed administrative or 
management tools for perforaiing various aspects of system and appUcation administration. 

For exanqile, appUcation servers may provide management tools related to an>Ucatioa development and 
deployment, such as tools for source code control and versioning, bug tracking, woikgroup development, etc 
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Application servers may also provide tools related to application testing and deployment, such as tools for 
application prototyping, load simulation, dynamic code base updates, etc. Application servers may also provide 
took for easily coniiguring the application to utilize various of the appbcation server services described above. For 
example, administrators may use a tool to set the result caching criteria for particular application components or 
pages, or may use a tool to specify which documents to index or to specify indexing methods, etc 

One important class of application server administrative tools pertains to reaktime applicaticni 
management and monitoring. Application servers may provide tools for dynamically managing various lactias 
affecting application performance, e.g. by adjusting the application services and support features described above. 
For exaxiq)le, application server tools may allow adnunistrators to: 

• dynamically adjust the number of database connections maintained in a database pool, in order to determine 
the c^timum pool size for maxirmma perfbrmanoe 

• clear or resize application output caches 

• dynamically change various aspects of system or applicatian security 

• schedule or trigger events, such as events for sending e-mail reports to application users, generating reports 
based on collected data, etc 

• start and stop various application services, such as email or FTP services, from a centralized user intertee 

Hus list is, of course, exeirq)lary, and particular appUcation servers may support difioent types of centralted 
application management. 



In addition to the factors discussed above, many application servers also inchide means for providing 
various types of system reliability and fault tolerance. One common technique related to fault tolerance is known 
as application server "chistcring". Application server clustering refers to tying together two or more application 
servers into a system. In some cases, this "tying together^ may mean that appbcation code, such as particular 
30 software components, is replicated on multiple application servers in a cluster, so diat m Uie case of a hardware « 
software faihirc on one application server, user requests may be routed to and processed by other appfication 
servers in ibc cluster. 

Application server clustering may also facilitate application performance and scalability. Application 
servers may be added to a chistcr in order to scale up the available processing power by distributing work- 
35 Advantageously, application servers often enable this type of scaling up to be down wifhoirt requiring changes to 
the application code itselil 

Work may be distributed across an application server chister in different ways. For example. as.discussed 
above, application code may be replicated across multiple appUcation servers in the chistcr, enablmg a given 
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request to be processed by aoy of these multiple appiication servers. Also, application code may be logically 
partitioned over multiple servers* e.g^ so that a particular application server is responsible for performing particular 
types of operations. This type of application partitioning may help application performance in various ways. For 
exanxple, application partitioning may reduce the need for an application server to perform context switching 
5 between different types of operations, such as CPUrintensive operations versus inpul/putput-intensive operations. 
Also, application partitioning may be used to match application processing to various physical characteristics of a 
system, such as netwoHc characteristics. For example, data-intensive application logic may be configured to run on 
an application server that is closest to a data source, in order to reduce the latencies associated widi accessing 
remotely located data. 

10 In the case of plication code replication, where multiple application servers are capable of processing a 

given request, it is often desirable to route the. request to the ^^st** application server currently available to process 
the request, i.e^ to the application server that will enable the request to be processed and Ae request results to be 
returned to the client as quickly as possible. This mapping of client requests to application servers is known as 
application server load balancing. 

15 Given the types of critical applications that may ran on application servcn, application failure iccovefy 

mechanisms are an especially important area 'for application servers to address. One possible point of ftihne in a 
system is between a client computer, such as a web server, and the application server. The tenn ""request faflover^, 
as used herein, refers to methods applied to prevent, detect, and/or recover irom failures that occur once a client 
computer performs a request and begins to wait on the request results. Existing application server request failovcr 

20 approaches often suffer from various disadvantages. For example, the client computer may rely on the c^Mrating 
system to inform the client coniputer of broken connections, which may result in a mudi longer fSbaa nebessary time 
interval for the broken connecdon to be discovered. 

SUMMARY OF THE INVENTION 

25 The problems outlined above may in large part be solved by a system and method for enabling application 

server requeist faDover, as described herein. The application server may support networked applications, such as 
web applications or other Internet-based applications. The applications may run on a system including one or more 
client compters, e-g., web servexs* that perform requests referencing application conqponents running on an 
application server. The system may also be configured to utilize a cluster of application servers in which requests 

30 from the client con7uter(s) are distributed across different application servers. 

For each application server request to be performed by a client computer, a particular thread rmmnig cm 
the client coixxputer may perform the request The requesting threads may be operable to utilize a custom wire*level 
communication protocol, as described below, for commimicating with an application server computer. Request 
failure detection mechanxsnis may be buih into the custom wire-level communication protocol so that a requesting 

35 thread detects a failed request, e.g., due to a lost connection between the client computer and the application server 
computer, an application server coxxqiuter failure, etc., much sooner than if the thread utilized a standard 
communication protocol and relied on the client computer openting system for notification of failed requests. 

After sending a request to an application server, a requesting thread may be operable to **sleq>**, using 
standard operating system techniques. The requesting thread may then periodicaUy wake up to poll the application 
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server computer to dcteiminc whether the request has failed. In one embodiment, diis pblling is performed by die 
requesdng Arcad sending a User Datagram Protocol (UDP) message comprising information identifying ibe request 
to die appUcation server. Upon receiving die UDP message, die application server is operable to use die request 
infomiadon to determine die stanis of die idendficd request and inform die requesting duead of die request status. 

5. If the requesting dircad receives a response from die application server computer indicating diat Ac 

request is not currently being processed, dxcn die requesting dircad may re-send the request Receiving no ttsponsc 
to die poll message may indicate diat die appHcation server computer is offline, e-g., due to a faihire* Id one 
embodiment, die application server con^uter may be one node in an appKcation server chistcr, as described above. 
In diis case, die requesting dnead may redirect die request to anodier application server conqHiler. The requesting 

10 dircad may update information maintained on die cKent computer regarding die status of each application server 
computer, to indicate diat die application server con^utcr to which die request was sent is currendy offlme. Fuoae 
requests will dien be sent to odier computers in die appUcation server cluster. The cKoit computer may attempt to 
poU die offline application seiver computer periodically, in order to determine when die offline application server 
becomes available again. 

13 

BRIEF DESCRIPTION OF THE PRAWWGS 
Odier objects and advantages of die invention wiU become apparent upon readii^ die foOowing detailed 
descr^tion and upon reference to die accompanying drawings in wfaidi: 

20 Figure 1 iDustrates a typical architecture for a web application utilizing CGI sor^ or prggiams; 

Figures 2A - 2C ilhistrate exenqilary architecmres for networked applications lunmng on application 

servers; 

25 Figure 3 is a block diagram fllustrating one embodiment of an application server and processes diat run on 

die ^iplication seivei; 

Figure 4 ilhisn^tes several system-level services diat may be involved in managing application server 
requests; 

30 . 

Figures 5 and 6 flhistratc various embodiments of a web server client widi a web server phig-in comprising 

a load balancer con^M>nent diat disttibutes requests across an application server cluster. 

Figure 7 iUustratcs a cluster of appHcation servers in which each application server comprises a load 
35 balancing service; 

Figure 8 illustrates a table of exen^lary server load criteria diat may be used in decidmg which appUcation 
server is best able to process a current request; 
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Figure 9 illustrates a table of exemplary applicatioD component performance criteria that may be used in 
deciding which application server is best able to process a current request;. 

Figure 10 illustrates an exemplary user interface screen for setting server load criteria values; 

5 

Figure 1 1 illustiates a user interface partial tree view of application serveis in an application server chistci; 

Figure 12 illustrates an exemplary user interface screen for setting application conq>onent performance 
criteria values; 

Figure 13 illustrates an exemplary user interface screen for setting broadcast and update intovals for 
sharing load balancing infomiation among application serveis in an application server chistei; 

Figure 14 illustrates an exen^laiy user interface of a tool for enabling administrators to specify ''stick/' 
15 load balancing for certain application components; 

Figure IS is a flowchart diagram illiistrating one embodiment of a method for enabling application server 
request failovei; 

20 Figure 16 is a flowchart diagram illustrating one embodiment of a method for ifynamically discoveriEg 

and rdoading classes; 



Figure 17 is a flowchart diagram iDustrating one embodiment of a method for deternuning whether a i 
should be dynamically reloaded when modified; 

25 

Figure 18 is a flowchart diagram illustrating one embodiment of a method for pexfonning atomic das^ 

loading; 

Figure 19 is a flowchart diagraxn fllustrating one embodiment of a method for enabling JSP response 

30 cachinig; 

Figure 20 illustrates an exeriq)lary user interface of a tool for managing message logging; 
Figure 21 illustrates an exen^lary type of database table for logging messages; 

35 

Figiire 22 illustrates an exeixxplaiy type of database table for logging HTTP requests; and 

Figure 23 is a flowchart diagram illustrating one embodiment of a method for handling out-of-storage- 
space conditions when logging messages. 
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WhOe the invention is susceptible to vaiious modiiications and altemative fonns, specific embodiments 
are shown by way of example in the drawings and are herein described in detafl. It should be imderstood however, 
that drawings and detailed description thereto are not intended to limit the invention to the particular form 
disclosed, but on the contrary the invention is to cover aU niodincations, equivalents and alternatives falling within 
5 the spirit and scope of the present invention as defined by the appended claims, 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

Figine 2 - Exemplary Application Architectures 

ID Figures 2A - 2C illustrate exeiiq>lary architectures for networked applications running on applicatioii 

servers. There are, of course, many possible architectural variations, and Figures 2A - 2C are exemplary only. 

Figure 2A illustrates an exen^lary architecture for a web application. In general, a web application may 
be defined as an Internet or Intranet-based application comprising a collection of resources that are accessible 
through uniform resource locators (URLs). The resources may include web pages conq;irising HTML, XML, 

15 scri|)ting code such as Javascr^ or VBScript, or other types of elements. The resources may also include any of 
various types of executable programs or components, such as CGI programs, Java servlets, JavaBeans componemis, 
CORBA components, dbiwnloadable code such as Java classes or ActiveX conxponents, etc Tlie resources may 
include any other type of resource addressable dmiugh n URL. 

The embodiment of Figure 2A illustrates a client computer 100 rumiing a web browser, such as the 

20 Netscape Navigator or Microsoft Internet Explorer web browsers. It is noted that the web-browser need not be a 
web browser per se, but may be any of various types of client-side applications Aat inc l ud e web-browsing 
functionality. For example, Microsoft Corp. provides programming interfaces enabling applicatiosis to incoipoo^ 
various w^browsing capabilities provided by Ihe Microsoft Imeniet Explorer code base. 

The web browser may run in any type of client computer 100. For example, the web browser may run in a 

25 desktop computer or workstation running any of various operating systems, such as Windows, Mac OS, Unix, etc, 
or the web browser may run in a portable computing device, such as a personal data assistant, smart ceDuIar phone, 
etc. The client conq)uter 100 may use a network connection for comsnunicating with a wd) server 104 via a 
netwo^ 102, such as the Internet or an Intranet. The client network connection may be a connection of any type, 
such as a PPP or SLIP dialiip link, an E&emet or token ring coimection, an ISDN connection, a cable modem 

30 coimection, any of various types of wireless connections, etc Aldiough web applications are often associated widi 
particular communication protocols, such as HTTP or SSL, it is noted that any communication protocol, including 
TCP-based protocols and UDP-based protocols, may be used to communicate over the network 102. 

As the web server 104 receives a request from a client computer 100, the web server may treat the request 
dificrently, depending on the type of resource the request references. For exanq>le, if die request refercBces a 

35 document 106, such as an HTML docinnent, then the web server may process the request itself e.g., by retrieving 
the doctunent from the web server's local iile system or from a local cache and retunung the document to the clieBt 
computer. For other types of requests, e.g. requests referencing executable conqwnents, such as Java servlets, 
JavaBeans con^nents, C program modules, CORBA components, etc., the web server may broker the request to 
an application senrer 108- As described in more detail below, the web server 104 may interface with an application 
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server through an in-process extension, such as an ISAPI or NSAPl extension. It is noted that it is possible to 
incorporate the functionality provided by the web server into an integrated application server. 

The application server 108 may be configured as a part of an application server cluster, as described above 
and shown in Figure 2A. Although Figure 2A illustrates an application server cluster with only two application 
5 servers, it is noted that the cluster may comprise any number of application servers. Each application server may 
interface with various types of other servers or systems. For example, as illustrated in Figure 2A, the appUcatioa 
servers may comnximicate with a database 110, Each application server in the cluster may interface with the same 
systems, or the application servers may differ in which systems they interface with. For example. Figure 2B is 
similar to Figure 2A, but in the embodiment of Figure 2B, application server 108B is shown to interface with a 
10 legacy system 1 12. Application servers in a cluster may not need to be in close physical proximity to each other. 

It is noted that, in altematiye embodiments, a client computer may conmiunicate directly with an 
application server or application server cluster, withotit interfacing through a web server. Figure 2C illustrates a 
client con^uter 1 14 communicating directly with application servers 108. For example, the application servers 
may run an enterprise resource plarming application, and the client computer 1 14 may be a con^niter within tfie 
15 enterprise that is cormected to the application servers via a WAN. In this example, the client con^uter may run 
'^thick client*" software, e.g., client software that coxx^rises a portion of the enterprise resource plaiming application 
- logic The client computer sofhvaxe may interface directly with executable programs or conqKincnts running on the 
application servers, e.g. through a protocol such as the Internet Inter-Orb Protocol (IIOP). 

As noted above. Figures 2A - 2C are exemplary architectures only, and many variations aie possible. As a 
20 small handful of examples of ahemative embodiments, multiple web servers may be present to receive requests 
from client con^uters and broker the requests to ^iplication servers, the web server may itself iaata&ot diiecdy 
with a database, application servers may interface with various other, types of systems, sudi as specsalized 
audientication servers, e-commerce servers, etc. 

25 Figure 3 Service and Component Management 

Applications that run on application servers are bflen constructed from various types of sofhvaie 
components or modules. These components may include corrq>onents constructed accordiitg to a standaid 
component model. For exan^le, an application may con^rise various types of standard Iava^conqx)nents such as 
Enterprise JavaBeans^ components, JavaScrver Pages^, Java Servlets^, etc. An application may also comprise 

30 any of various other types of con^onents, such as Common Object Request Broker Architecture (CORBA)' 
con^nents, Conunon Object Model (COM) components, or components constructed according to various 
proprietary component models. 

Each request that an application server receives from a ch'ent may reference a particular af^lication 
con^nenL Upon receiving a request, the application server may determine the appropriate component, invoke die 

35. con^nent, and return the execution results to the client In various embodiments, it may be necessary or desirable 
for different types of application server components to run within different envirorunents. For exanq>le, an 
application server may support both components written using the Java^ progranuning language and components 
wrinen using the C or C-H- programming languages. In such a case, the different types of con^onents may be 
managed by particular processes or engines. 
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For example. Figure 3 illustrates an application server 200 in which a process referred to as the ''executive 
server" 202 runs. As shown, ihc executive server 202 interfaces with a process 204, refened to as a "Java server^ 
and a process 206 jefcTxcd to as a "00++ server''. In this embodiment, the executive server 202 may receive cUent 
requests, assign the client requests to a particular thread, and forward the requests to cither the Java server 204 or 
the CyC++ server 206, depending on whether the requests reference a component that executes within a Java 
runtime environment or a C/C-m- runtime environment The Java server or aC++ server may then load and 
execute the appropriate cojiiponent ox modole. 

In addition to interfacing with the Java and OC^ servers, the executive server 202 may also manage 
various system-level services. For example, as discussed below, the executive server may manage a load balancing 
service for distributing requests to other application server computers in a chister, a request manager service for 
handling incoming requests, a protocol manager service for communicating with clients using various protocols, an 
event logging service for recording conditions or events, etc. 

In addition to managing application components, the Java server 204 and the C/C-m- server 206 may also 
host and manage various application-level services used by the appKcation components. These appfication-levcl 
services may include services for managing access to databases and pooling database connections, services for 
performing state and session management, services for cachmg ou^ut results of particular application con^onents, 
or any of various other services such as described above. 

Figure 3 also ilhistrates a process 208 referred to as the "administrative server^. As described above, an 
application server environment may provide an administrative tool for adjusting varioos foctors affecting 
application execution and performance In the embodiment of Fig;ure 3, such an adminisoative tool may interface 
with the administrative server 208 to adjust these factors. For exanr^lc, tibc administrative tool 208 may be enabled 
to adjust the event logging criteria used by the executive server's event-logging service, adjust die number of 
database connections pooled by the Java or C/C++ server's data access service, etc. Tlie administnitive server 208 
may also provide faihirc recovery by monitoring the executive server, Java server, and Oe++ server processes and 
restarting these processes in case of faihne. 

Figure 3 of course represents an exemplary architecture for managing application conq>onents, system* 
level services, and appKcation-level services, and various other enibodimcnts are contesnplated.. For example, 
although Figure 3 is discussed in terms of Java^ and C/C++ components, various other processes or engines may 
be present for execudng other types of software components or modules. Also, various embodiments may support 
multiple component management processes, e.g. multiple Java server processes or aC++ server processes. Tlie 
number of processes may be adjusted via an administrative tool interfacing with the administrative server. 

Figure 4 - Application Server System-Level Services 

Figure 4 iDustrates several system-level services which may be invoked in managing application senw 
requests. In one embodiment, these system-level services may be managed by an executive server process such as 
described above with reference to the Figure 3 application server. 

Figixre 4 ilhistrates a protocol manager service 220. The protocol manager service 220 is responsible for 
managing network communication between the application server 230 and clients of the application server. For 
cxanqjle. Figure 4 fllustrates a web server client 240 which comprises a standard web server extension or plug-in 
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242. The web server plug-in 242 may be any of various well-known types of plug-ins enabling web servers to 
communicate with other systems, including NSAPl, ISAPl, optimized CGI» etc. As shown, the protocol managei 
seivice 220 includes *iistener^ modules or components, e.g. an NSAPI listener, ISAPI listener, etc^ for* 
communicating with the web server plug-in. The listener modules may commtmicate with the web server plug-m 
via the standard HTTP or HTTPS protocols. 

Figure 4 also illustrates that other types of clients besides web servers may comsnimicate witfi die 
application server 230. For example, a clienl computer 250 is shown. The client computer 250 may run an 
application program, such as a program written in Java™ or C+-t>. that communicates with the application server 
230 using any of various communication protocols. For example; as shown in Figure 4, Uie protocol manager 
service 220 may support such protocols as IIOP, RKO, DOOM, OCL Service, or any of various other protocols. As 
an example, an administration program for coniiguring an application server may comnnmicate dirixtly with the 
application server 230 through such a protocol, rather than routing requests through a web server. 

As shown in Figure 4, an application server may also include a load balancing service 222. In the case of 
application server clustering, requests may first be processed by the load balancing service in order to determine 
whether the request should be processed by the cturrent application server or would be better served by forwarding 
the request to another application server in the cluster. Load balancing is discussed in detafl below. 

As shown in Figure 4, an application server may also include a request manager service 224.. Once die 
load balancing service determines that the current application server should process the client request <if load 
balancing is applicable), the request manager service is responsible for managing, the processing of die request. As 
shown in Figure 4, the request manager service 224 may include several components or m odu lrs, siicfa as a request 
manager, a thread manager, and a queue numager. In one embodiment client requests may be processed in a nniltH 
threaded fashion. The thread manager module may manage a pool of threads available for procrss i ng requests. In 
one embodiment, the niunber of threads in the pool may be adjusted using an adminisiratrve tooL 

When the request manager module receives a client request, the request manger module may call die 
thread manager module to anempt to assign the client request to a thread. If no dueads are currently available, then 
the request manager module may call the queue manager module to queue the request until a thread beco^Bes 
available. The queue manager module may maintain information regarding each client request, such as die reqtiest. 
ID, the processing status, etc. 

Application Server Load Balancing 

As discussed above, it is often desirable to configure a cluster of application servers so that cUcnt requests 
may be distributed across the cluster, i.e., to perform application server load balancing. Given the diverse nature of 
applications that may be deployed on application servers, it may be desirable to provide a system whose load 
balancing criteria are highly configurable ttsing many different factors in order to achieve optimal application 
performance. This section discusses several load balancing methods. In various embodiments, application servers 
may support any of these load balancing methods or any combination of the load balancing methods described. 
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Load iSalancing Dciennmed by Web Server Plug-In 

One general approach which may be used in selecting an application server to send a request to is to leave 
the decision to the client The client may keep track of the icsponse times seen over time from various appbcation 
servers and may choose to send requests to the application server with the historically fastest response times. In 

5 many cases, the "client" of an application server is a web server. As shown in Figure 4, a web server may have a 
web server phig-in which includes a load balancer componcm or module. This load balancer conqM>nent may be 
lesponsible for monitoring which application scrvcfs are available in a cluster to service requests, may record fht 
response times seen for requests serviced by each application server, and may use this information to determine die 
most appropriate application seiver to send a given request to. 

]Q The load balancer component of the web server phig-in may be configured, using an administrative tool, to 

use difTcrent levels of granularity in making the response time decisions. As discussed above, client requests 
generally reference a particular executable component on an application server. For example, a URL sudi as 
*nittp://server.domain.com/abc.jsp'* may reference a JavaServer Page™ component, "abc,jq>-. In an excmplaiy 
system in which the "abc.j^- component is replicated across three application servers. Application Server A,. 

15 Application Server B, and Application Server C, the average response time, as seen from the time die request 
referencing the "abc.jsp- conq>onent is sent to the application server to the time the request results are received 
. from the application server, may be as follows: . 

Application Server A: 0.7 sec 

20 Application Server B: O^aec 
Application ScnwO 13 sec 

In such a case, it may be advantageous to enable the load balancer conq>oncnt of the web server to send a request 
referencing the •*abc.jsp" component to Application Server B. In other words, load balancing may be performed on 

25 a •^cr-componcnt" basis, where each request referencing a particular component is sent to the application server 
which has historically responded to requests for that component die fastest 

Performing load balancing on a per-corr^onent basis may benefit application performance for certain 
types of applications. However, for odier applications, tracking such response-time information <» a per- 
component basis may resuh in overhead diat outweighs the benefits. Thus, Ae load balancer component of the w«* 

30 server may also make decisions on a ^-scryeT basis. That is, die determination of which application scnrer to 
send requests to is based on die average response time for all requests. It is noted diat m one embodiment die per- 
server and per^onqjoncnt mediods may be combined, so diat administrators may specify a particular set of 
components for which die load-balancing decisions are made based on a per-corrqxment basis, while decisions are 
made on a pcr-server basis for default conqKments. 

35 Figure 5 illustrates one embodiment of a web server client 300 widj a web server plug-in 302 comprising a 

load balancer conq)onent 304 which distributes requests across an application server chister (appUcation servers 
308A - 308Q. As shown, die load balancer component 304 may maintain a table or list of response times 306, to 
be used in making load balancing decisions as described above. 
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Tlie client, e.g., the load balancing component of the web server plug-in, may also make load balancing 
decisions based on factors other than lesponse times. For example, in one embodiment, administrators may assign 
a *Veight'* to each application server in a cluster, using an administrative tooL A weight may be assigned to each • 
application server* based on the server's resources, such as the number of CPUs, the memory capacity, etc The 
5 application server weights may dies be used in various request distribution algorithms, such that requests are 
distributed among the. application servers in proporuon to their weights. For exanqple, Wjcights may be used m a 
weighted round*robin algorithm or may be applied to enforce even distribution for certain types of requests, as 
described below. 

Figure 6 illustrates one embodiment of a web server client 300 with a web server plug-in 302 comprising a 
10 load balancer conq>oncnt 304 which distributes requests across an application server cluster (application servers 
308A * 308C). As shown, a weight is assigned to each application server in the cluster, and the weights are used m 
a weighted load balancing algorithm. 

Load Balancing Determined by Application Server Load Balancing Service 

IS Instead of leaving load balancing decisions to the client, based'on such factors as response times and 

server weights, in various embodiments the appHcation servers themselves may be responsible for distributing 
requests among different computers in the application server cluster. For exanq>le, in the Figise 4 exanq>le, the 
application server 230 comprises a load balancing service 222 that performs request load balancing. Figure 7 
fllustiates a chisier of application servers 320A - 320D in which each application server comprises a load balancigg 

20 service330. 

Hie load balancing services of the application servers may share infonnaticMi to be used in deciding vindl * 
application server is best able to process a current request One class of information that may be factored into diis 
decision is refened to as ''server load criteria.*' Server load criteria includes various types of information .^t may 
be indicative of how "busy** an application server currently is, such as the CPU load, the.input/ou^ut rate, elc 
25 Figure 8 illustrates a table of exemplary server load criteria. Any of various other factors aflecting server 
performance may be considered in. odier enibodimeiits. 

Another class of information that, may be factored into load balancing decisions is referred to- as 
"application component performance criteria**. Application component performance criteria mchides informatioo 
regarding the performance of a particular application component, e.g. a particular JavaServer Pages^ component 
30 Figtne 9 illustrates a table of exerr^lary criteria that may affect applicadon component perfomoance. For exaxzq>le. 
Figure 9 illustrates a '<^ched Results Available" critcrioiL As discussed below, in various embodiments, tbe 
execution results of application components, such as JavaServer Pages^ con^nents, may be cached. Reusing 
execution results cached on a particular application server may result in faster processing of a request 

Another exeinplaiy criterion listed in Figure 9 is ''Most Recently Executed**. For some types of 
35 application components, distributing a request to the application server .that most recently ran the applicatign 
coniponent referenced by the request may result in faster proccssii^ since that application server may still have 
context information for the application component cached. 

Another exemplary criterion listed in Figure 9 is ^Fewest Executions**. In some cases, it may be desirable 
to distribute different types of requests evenly across all appHcanon servers in a cluster. Thus, the application 
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server that has run.the application component referenced by a request the fewest number of times may be chosen to 
process the request 

Any of various other factors regarding application con^onent performance other than those listed in 
Figure 9 may be used in other embodiments. 

5 Figures 10-12 illustrate an exemplary user interface of an administrative tool for adjusting load balancing 

factors such as those described above. Figure 10 illustrates a user interface screen for setting server load ciiteria 
values, such as those shown in the Figure 8 table. Administrators may adjust the weight for each factor as 
appropriate, in order to maximize performance fen* a particular application server. 

Note that the server load criteria values may be adjusted separately for each application server, as desired. 

10 Figure 1 1 illustrates a partial tree view of application servers in an application server cluster. In Figure 1 1, a siiigle 
application server name, *74AS1**, is shown, along with various application conq>onents that run on the ^l^ASl** 
application server. For example, in the embodiment shown, various Enteiprise JavaBeans™ ^t run on the 
•T^ASl- server are shown under the ''EJB'* heading. The screens shown in Figures 10 and 1 1 may be coupled so 
that the server load criteria settings adjusted on the Figure 10 screen apply to the application server selected on tibe 

IS Figure 1 1 screen. 

Figure 12 illustrates a user interface screen for setting application componem performance criteria values, 
such as those shown in the Figure 9 table. Administrators may adjust the weight given to eadi fiictor as 
approp riate, for each application component, by selecting the desired application component similarly as described 
above. The •*scrver load" vahie shown in the Figure 12 screen may be a composite value con^nited using the 

20 Figure 10 server load criteria values. Thus, the load balancing criteria for each particular application component 
may be fine-tuned using a variety of factors, in order to achieve maximum performance for a particular system or 
application. The user interface may of course allow default load balancii^ criteria to be specified, may allow load' 
balancing criteria for muh^le application components or multiple servers to be specified or copied, etc 

Note that in Figures 10 and 12, *^scr-Defined Criteria** is selected in the *Xoad Balancing Mediod** field 

25 at the top of the screens, so that load balancing decisions are made by the application server load balancin g 
services. The user interface may also allow the administrator to specify that load balancing decisions are made by 
the client, e.g., the web server plug-in, as described above with reference to Figures 5 and 6^ by selectii^ a difTercDt 
option in this field. 

Referring again to Figure 7, the figure illustrates that the load balancing services 330 in each application 
30 server 320 may communicate with the load balancing. services of other application servers in the cluster in order to 
share information, such as the server load criteria and application con^nent performance criteria described above. 
In one embodiment, the load balancing services communicate using standard User Datagram Protocol (UDP) 
multicasting. 

In one embodiment, intervals for both broadcasting and updating load balancing infonoiation may be set 
35 using an administrative tooL Figure 13 illustrates one embodiment of a user interface screen for setting broadcast 
and update intervals. The *3ase Broadcast/Update Interval** field refers to a base interval at which the load 
balancing service *Svakes up** to broadcast information for its respective application server to the load balancing 
services of other application servers, to check to see whether any updated information was received fiom other load 
balancing services, and to update the load balancing information with any received updates. The other intervals 
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shown in Figure 13 arc relative to the base broadcast/update interval. For example, the ^Application Component 
Criteria** broadcast interval is two times the base interval^ so that application component performance infoimatioii 
is broadcast every other time the load balancing service wakes up. Note that performance infonnation for a given 
application component may be exchanged only between application servers hosting that applicatiaii<on^nciit» ia 
5 order to avoid tmnecessary network*tiaffic 

Figure 13 also illustrates fields for setting the broadcast interval server load infonnatioii» and the update 
intervals for information described above, such as the server load value, CPU load. Disk Input/Ou^iit, Memory 
Thrash, and Number of Requests Queued. By adjusting the various broadcast and update intervals appropriately 
for a given application or system, the optimum balance between fresh load balancing data, server update overhead, 

10 and network traffic may be achieved. 

The information shared among application server load balancing services may be used to dynamically 
route a request received from a client to the *i>est** application server for processing the mjaegL As *««-««^ 
above, each client request may reference a particular application componenL The decision as to which application 
server processes a request is preferably made based on the stored informatioii regarding die panicidar applicatian 

15 continent Thus, at any given time, the ^est^ application server for processing a request may depend on die . 
particular application component that the request references, depending on how the server load criteria and 
application component performance criteria arc chosen, as described above. 

If the load balancing service of die application server that initially receives a request fiom a cheat 
determines that another application server is currently better able to process the request* dien the ze<]uest may be 

20 redirected to die other application server. As shown in the Figure 13 user interface, administratOTB may specify a 
maximum number of "^ops**, i.e., the maximum number of times that a request may be redirected before it is 
processed by the application server that last received the rcquesL The hop number may be updated in die request 
information each time the request is redirected. As the processed request is passed back to the chest, e^g., the web 
server phig*iii, die client may record die applicadon server that ultimately satisfied die. request so diat a similar 

25 future request would dien be sent by the client directly to that applicadon server. 

*^'cky* Load Balancing 

Administrators may mark certain application components for ^sticky** load balancing, meaning that 
requests issued within the context of a particular session that reference that application component are all processed 

30 by the application component instance mnning on the same application server. Some application components may . 
need to be marked for sticky load balancing, especially if the components rely on session informatioB that cannot 
be distributed across application servers. Such situations may arise, for example, if an application is originally 
written to run on one computer and is then ported to a distributed application server duster 

As an example of sticky load balancing, suppose that an application conq>onent called **ShopCarf* is 

35 duplicated across two apphcation servers. Server A and Server B, for load balaikcing. If a first client. Client 1 
performs a request referencing the SfaopCart con^onent, then the ShopCart instance running on either Server A or 
Server B may be chosen to process the request, depending on the outcome of die load balancing decisions described 
above. Suppose that the Server A ShopCart instance processes the request Then, if die ShopCan con^xmem is a 
component marked as requiring sticky load balancing, any further requests issued by CUcnt 1 that reference the 

13 



BNSOOClOt «WO l3227Aa.l_» 



wo 01/13227 PCT/US00/2205S 

ShopCart component will also be processed by the Server A ShopCart component, regardless of the other load 
balancing criteria. Requests by other clients referencing the ShopCart component may of course be processed on 
other servers, e.g,, on Server B, but then those requests too would "stick- to the application component instance 
^ere they were first processed. 
5 Figure 14 illustrates an exemplary user interface of a tool for enabling administrators to specify sticky load 

balancing for certain application cornponents. Figure 14 illustrates a group of application conqsonents which, for 
cxan^le, may be displayed by navigating through a hierarchy nrce such as shown in Figure 11. The **Sticky LB"* 
column of the user interface has a checkbox allowing sticky load balancmg to be nmaed on for paxticular 
application components. 

10 Although some existing application server systems support sticky load balancing* the information requixed 

to dctennine the correct application server that should receive a given sticky request is often maintained on die 
server side. This may rcsuh in the client computer sending a sticky request to a fust application server which then 
redirects the request to a second application server that should process the sticky request. To overcome dus 
inefficiency, the client computer(s) may instead be operable to maintain information regarding sticky requests so 

IS that requests are sent directly to the correct application server. 

In various embodiments, the application server system may also enforce even disnibution of sticky 
requests. As noted, the initial request to a componem requiring stickiness may be made using normal lomd 
balancing methods, such as those described above. At any given time, these load balancing methods may 
determine that a particular application server is the -besT server to process a request Thus, it may be possible fliat 

20 a particular application server receives a large batch of initial requests referencing sticky components. Since eadi 
session that sent an initial sticky request to the application server is then bound to diat ^Hcation server te 
subsequem requests, the result may be a decrease in application performance over the long tenn. 

Thus, the system may track information regarding the number of sticky requests that are cmxently bound 
to each application server and may force the sticky requests to be distributed roughly evenly. In one embodiment, 

25 administrators may assign a weight to each application server, such as described above, and the sticky requests may 
be distributed in proportion to these weights. 

Graceful Distributiop 

Some existing application server load balancing systems use a •Svinncr-take-alT strategy, in which all 
30 incoming requests at any given time are assigned to the calculated "bcsf application server. However, experienoe 
in the application server field has shown that the result of such a strategy may be cyclic pattern in whidi, at any 
given time, one application server may be under a heavy load, while other servers are mostly idle. This problem 
may arise in part from load balancing information being shared at periodic intervals, rather than in real time. 

Thus, in various embodiments, -gracefuT load balancing methods may be utilized, in which the •tetf 
35 application server at a given time moment or interval, as defined by criteria such as described above, is assigned die 
largest nuixiber of incoming requests, while other appUcation servers, or a subset of the other application servers, 
are snll assigned some of the incoming requests. Such graceful load balancing may be performed using any of 
various methods. As a simple example, a weighted random distribution algorithm may be used. For exanq>le, for a 
cluster of application servers of size L, a random number between 1 and L may be generated, where the generated 
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number designates the number of the application server to assign the request to, and where 1 represents the current 
'Tjcst" applicauon server to process the request and L represents the application server at the other end of the 
spectrum. Thus, the random number is generated in a weighted manner, such that the probability of choosing a 
server number diminishes going from 1 to L. The resulting request distribution panem may then appear similar to a 
5 y « 1/x graph pattern. 

This type of graceful request distribution may be applied at various levels, depending on a particular 
application or system. For example, as described above, one general load balancing approach that may be used is 
to leave the distribution decision to the client. e.g., by tracking the response times as seen from each application 
server. Thus the client, e.g., the web server plug-in, may rank the application servers by their response times and 
10 ''gracefully" distribute requests among the application servers, thus helping to maintain an even work load among 
the application servers at all times. On the other hand, if load balancing decisions are made by the load balancing 
services of the application servers themselves, as descnbed above, then these load balancing services may employ a 
type of graceful distribution algorithnt 

IS Request Failovcr 

As described above, requests may be brokered from a client such as a web server to an application server. 
In some instances, requests may fail, e.g., due to a lost connection between the client and the application server, an 
application server failure, etc Depending on the communicadon protocol used to perform the request, requests 
may time out afte a certain time period. ' For example, a TCP/IP-based, request may timeout after a configurable 
20 time period. The timeout time period may or may not be conf^rable, depending on die cnv iiouu i ent , such as the 
particular operating system. Note that the typical default dnieout period inay be large, c.g. 30 imnutc^ If a request 
fails, e.g. due to a server power failure, other requests may be forced to wait while the requesting thread waits for a 
response that win never come. 

Figure 15 is a flowchart diagram illustrating one embodhnent of a method that may overcome diis 
25 problem In step 470, the client corriputer sends a request to an application server using a custom wire-level 
communicadon protoccd. The use of such a protocol may enable the cliem cosoputer to detect aiid recover from 
failed requests, as described below. Note that this custom protocol may be implemented as a protocol using varions 
standard communication protocols, such as the TCP/IP proiocoL 

In one embodiment, each request is performed by a separate thread ruiming in the cliient computer. In step 
30 472, the requesting thread sleeps, using standard operating system techniques. 

As shown in step 474, the requesting thread inay periodically wake up to poll die application server for 
information regarding the status of the request. The time interval for which the requesting thread sleeps between 
performing these polling operanons may be configurable by system administrators via a provided user interface. In 
one embodiment, the requesting thread may poll the application server by sending a User Datagram Protocol tUDP) 
35 message comprising information identifying the request to the application server. For exaniple, each request sent to 
the application server may comprise a request ID enabling both the client con^ter and the application server to 
track the request Upon receiving the UDP message, the application server is operable to use the request 
information to determine the status of the identified request and inform the requesting thread of the request status. 
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In step 476, the requesting thread detennines whether a response to the poll message was received from 
the application server. For example, the requesting thread may simply wail for a response for a pre-set, relatively 
short time intervaL 

If a rcsponsfe to the poll message is received, then in step 478. the requesting thread analyzes the response 
5 to determine the current stams of the request, as infonned by the application server. If the request is currently beiqg 
processed by the application server, then the requesting thread may simply retura to sleep, as shown in step 480. 
Note that this check can thus not only detect failed requests, but may also enable the application server to process 
requests that take a lot of time to process and that would resuh in request timeouts if standard co mmunic a tion 
protocols were used. 

10 If ihc request is not currently being processed by the application server, then the request failed for some 

reason, e.g^ due to a broken nenvoik connection, an application server error, etc. As shown in step 482, the 
requesting thread may then re-send the request and then rc-pcrform steps 472 - 488. The requesting thread may be 
operable to atten^t to send the request to the same application server a certain number of times before conchidiqg 
that requests to that application server arc failing for some reason and then anen^ting to send ihc request to a 

15 different application server, if the application server is part of an application server cluster. 

If no response to the poll message was received in step 476, then in step 484, the requesting thread may 
send the request to another application server, if the application server is pan of an application server chister. 

The client computer preferably maintains information regarding the current state of each application server 
in the chister. In step 486, the application server that did not reply to the polling message may be marked as 

20 ''ofOine*' so that further requests will not be sent to tfiat application server. 

As shown in step 488, the client computer may be opeiable to periodically poll die failed applicatioii 
server to detennine whether the applicatian server is online again. For example, the diem conqputer may nm a 
thread that maintains the application server status information and periodically polls the application servers marked 
as being ofiline. If so, then the application server status infomnation may be updated so that Ac application server 

25 is placed back in rotation to receive client requests. 

Pass Reloading 

In various embodiments, an application server may allow some application con^Nments, such ts Java 
Servkts*™ and JavaServcr Pages'**, to be dynamically reloaded while the server is ranning. This enables 
30 administrators to make changes to an application without restarting. Having to stop/restart an application is, of 
course, a serious problem in many situations. As described below, administrators may specify which classes wfaicfa 
are to be considered ^Versionable**, or dynamically reloadable. 

A versioning scheme is described with die following design points: 
35 • Not all classes are versioned by default. A distinction is made between "versionablc" and •^on-versionablc" 
classes. As described above, venioning classes bydefauU often suffers from various drawbacks. 
• Veision all major con^nents - If client's classes are TCjmwn" (see definition belowX then vexsioning will 
happen amomaticaDy. 



18 



BNSOOCIOc ^WO pi l3227Aaj.> 



wo 01/13227 PCTAJS00/22iB5 

• User. Configurable - For those client classes that are not "Known", the client may perform additional steps 
during deployment time to set up environmental variables. Users can then explicitly specify additional 
application-level classes that should be versionablc. 

• Interfaces are preferably not versioned to avoid runtime conflicts that may be caused by dynamically updating 
5 interfaces. 

The user may designate some classes as system classes. System classes preferably are not versioned. Certain 
classes may be designated as system classes by default 

Under the versioning scheme described herein, a user may control class versionabilityAeloadability by 
10 using the following environment entries, which may be inq>lemented as registry entries. A user interface may be 
provided for managing these settings. 

• GX_ALL_VERSIONABLE 

A non-2ero value for this entry causes all classes to be considered versionable. The defatih vahie is zcxo. Tbis 
15 entry may be used for backward compatibility with other systems. 

• GX^VERSIONABLE 

This entry comprises a semicolon-delimited list of classes that are to be considered by the system as versionable 
classes. By default, the list is empty. 
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• GX_VEIlSIONABIJE.IF.EXTEhlDS 

This entry comprises a semicolon-delimited list of classes. If a user's class extends a class in this list, then die 
user*s class is considered to be versionable. The default class list contains the javaxjservleLGenereicScrvleC and 
javax.servletJ)ttpServlet classes. Users can append addidonal classes to this list 

• GX_VERSIONABLE_IF_IMPLEMENTS 

This entry con^rises a semicoIonnSelimited list of interfaces. If a class implements an interface in diis list, then the 
class is considered to be versionable. The defauh interface list contains the javax.servlet.Servlet interface. Usen 
can append addidonal interfaces to this list . 



• GX_TASKMANAGER_PERIOD 

A timed thread wakes up periodicaUy to check for any classes that may need to be reloaded. If a user modifies a 
versionable class, the thread may instantiate a new classloader to dynamicaUy reload the modified class. The sleep 
time period for the diread may be set by setting the vahie of the GX_TASKMANAGER_P£RICM3 registry cntiy. 
35 The default vahie for Ihe GX.TASKMANAGER.PERIOD entry is '*10*' setonds. 
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Known gasses 

The class loader may detennine whciher a class that needs to be versioned is "known" based on its 
inheritance ttee. The class loader checks for the class's super classes and implemented interfaces to determine 
whether they are in the GX_VERS10NABLE_IF_EXTENDS or GX_VERS10NABLE_IF_1MPLEMENTS Vsts. 
respectively. If there is a match, then the derived class is considered "known". 

This system works particularly well in situations where aO or most classes diat need to be runtime- 
versioned are subclasses of a relatively smaU set of super classes. For example, in die case of seivlets. aU sen^ 
classes that are versionable may be subclasses of the javax.servlet.GenericServlet m javax^servletHnpServlet or 
they may aU implement die javax^servletServlet interface. 

In one embodiment, JSP fdes are versionable by default Hiey can easily be identified not by dteir 
inheritance, but by their file name exter>sion of •.jsp. 

For any given class name diat d»e classloader is asked to check, die classloader may locate die dass fife in 
die file system, dien parse the chBsfile in order to identiiy its immediate superclass as well as aU die interfices 
implemented by die class. It is important to note dist during die check, die class loadermay only examine die 
cbssfDe in die fde system to determine versionabOiiy and may not actuaUy load die dass into die ^em in order 
to examine it Due to die cache stickiness of die JVM concerning loaded chases, previous experiments have shown 
diat it is usually a bad idea to load a class to determine die versionabflity of it Thus die "normal- way to make 
one's ctoss versionable is to extendTunplement diose classes specified in die above-mentioned registry entries. 

Issuing a Warning While Serializing Non-version able Classes 

One potential problem occurs when an object d»t is being serialized in die session/state module refen to 
anodw object whose cbss is versionable. fa order to detect potential enors downstream, die session/state code can 
be modified so diat when a client session is being serialized, a sub-cbss of die stream ctess is instantiated. In dus 
subclass an inquiry is made regarding each class Aat is being serialized. If such a cbss is determined to be 
-venionable" (as defined by die above-mentioned rules), die system may issue or log a warning, nds detection 
mediod works widi beans and servlets which inclement die serializabfe inteifece. 



Ariy cache widiin die system which may contain versionable chisses (e.g.. EJB container, servlets. JSPs) may 
provide an interface so diat a class can be purged from the cache on a per-class basis, eg., by specifying die name 
of die class to purge. Each component that pools versionable objects should provide a medianism enabling die 
classloader to inform diem d«t die cUiss versions for diose objects have changed, and diat die pool should dms be 
purged. For example, an application server Java~ Servlet rminer or Enterprise JavaBeans** container may 
inqdement such interfaces. 

lirrolementation Details 

In one embodiment, diere are diree dilferent cbss loaders woricing inside die system at any given time: 
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• The Primordial Classloader (PCL) - used to load any core classes and any native code using "workaround* core 
classes 

• Engine ClassLoader (£CL) - A dassloader (risore precisely a series of engineOassloadevs) used to load aO 
versionable classes 

• Non Versionable Classloaders (NVCL) - A dassloader used to load all non-versioriable classes. There is only 
one such dassloader, which is preferably never replaced. 

A loadClassQ call may first determine whether the class in question is versionable or not» and then use tlie 
appropriate classloader to load the class. 

Figures 16-17: Vcrsioning Flowcharts 

Figure 16 is a flowchart diagram illustrating one embodiment of a method for dynamically discovering 
and reloading classes, based on the descriptions above. 

In step 400 of Figure 16, a timed thread wakes up to check for modified classes. It is noted that it may 
only be necessary to chedc for changes in certain classes, since classes are not yersioned fay default in one 
embodiment, the list of versionable classes may be determined once, c.g. using the method shown in tfaeTigme 17 
flowchart, and die list may be reused by the timed thread each time the thread wakes up. If an administrator 
changes the versionability settings, the list may be updated. Each class in the list may be checked for modifications 
in any way appropriate for a particular environment For example, the apphcation server may record the date and 
time of the class file when the class is first loaded and may check to determine whether the file has since been 
modtfiucdL 

As shown in step 404, if no modified versionable classes are found, the diread may simply letum to sleqi. 
If one or more modified classes are found, then steps 406 - 410 may be pei f oimed for each modified -class. 
In step 406, a new classloader is instantiated. 

In step 408, die dassloader instantiated in step 406 is used to reload the modified class. 

In step 410, the modified class may be purged from any caches maintained by the application server. As 
described above, any application server- components that maintain caches may provide interfaces for pinging a 
modified class from the cache. 

It is noted that Figtire 16 represents one embodiment of a method for dynamically rcloadiivg classes, and 
various steps may be added, omined, combined, modified, reordered, etc. For example, in some envircmmcnls it 
may not be necessary to instantiate a new dassloader for each class to be reloaded. 

Figure 17 is a flowchart diagram illustrating one embodiment of a method for determining whether a class 
is versionable, that is whether the class should be dynamically reloaded when modified. 

In step 420 of Figure 17, it is determined whether the class* name is listed in the GX_VERSIONABL£ list 
(described above). If so. then the class is versionable. 

In step 422, it is determined whether one or more of the class's superclasses are listed in the 
GX_VERSIONABL£.IF_EXT£NDS list (described above). If so, then the class is versionable. 
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In step 424, it is deiennined whether one or more of the interfaces implemented by the class are listed in 
the GX_VERS10NABLE_IF_1MPLEMENTS list (described above). If so, then the class is versionabk. 
Otherwise, the class may not be versionable. Modifications made to non-versionable classes may be ignored wWle . 
an application is nmning. 

5 It is noted that Figtue 17 represents one embodiment of a method few determining whether a class is 

veraonable, and various steps may be added, ooiitted. combined, modified, reordered, etc. For exan^le. steps 420 
- 422 may be performed in any OT<to desired. 

It is noted that an application server utilizing the methods described above widi reference to Figures 16 
and 17 may advantageously not consider interfece classes to be versionable by default, thus helping to enforce 

10 interface contracts between conq>oneals. 

Atomic gass-Loading 

It is often desiiiWe to update a set of classes aiomicaHy, Le, to have aU dynamic reloading changes for 
each ctoss in the set oke effect at the same time. Without an ability to perform atomic class-loading, errors may 
15 result when classes are dynamically reloaded. 

Figure 18 is a Howchart diagram iUustiating one embodiment of a method for perfonning atomic class- 
loading. As shown in step 440, an administrator may specify a set of class files to be treated as a "bundte". For 
example, the application server may provide a user interfece for managing and deployiAg class files fiom a . 
development environment to the runtime systeoL TTiis user interface may enable the administtator to define or edit 
20 a class bundle. In one embodiment, a componem referred to as the -deptoyer manager- pw^ 

In step 442. the administrauw requests the appUcation server to d^loy the class bundle q>ecified in stq> 

440^ e.gn using the tiser inter&ce described above. 

In response to the adininistrator's request in step 442, the deployer manager rnay obtains a lock referred to 

as the -dirtyaassListLodc" in step 444. The dirtyClassListLock may be implemented in iay of various standard 
25 ways. e.g., as a semaphore. The timed thread descn^ed above that dynanwadly discovers and reloads modified 
versionabk ctosses may also require the dixtyaassListLock. TTius. White the deployer muiager holds the 
dirtyClassListLock, the timed thread may not proceed. 

After oboining the dirtyClassListLock. the deployer manager copies aU class fdes in the bundle to their 
appropriate runtime locations in the file system in step 446. 
30 The deployer manager then releases the dirtyClassListLock in step 448. 

As shown in step 450. the timed thread can then resume itt normal check for modified classes. Thus. aD 
the new classes from the btindle are j»ocessed and loaded together. 



JavaServer Pages™ Caching 

35 This section provides an overview of JavaServer Pages™ (JSP) technology and describes a caching system 

and method for JSP component responses. JavaServer Pages™ (JSP) is a Java™ platform technology for building 
applications streaming dynamic content such as HTML. DHTML. XHTML and XML. JavaServer Pages is a 
Standard Extension that is defmed on top of the Servlet Suindard Extension. JSP 1.0 uses the ctosses from Java 
Scrvlet 2.1 specification. For more information on JavaServer Pages™, pkase refer to the JavaServer P8ges« 
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Spccificadon^ Version 1.0, available from Sun Micros>'stejns, Inc. For more infoimadon on Java servlels, please 
refer lo the Java Servlet 2.1 Specification, available from Sun Microsystems, Inc. 

A JSP component is a text*based document thai describes how to process a request to create a response. • 
The description intermixes template data with some dynamic actions and leverages on the Java"™ Platform. In 
5 general, a JSP component uses some data sent to the server in a client request to interact with information already 
stored on the server, and then dynamically creates some content which is then sent back to the client The content 
ban be organized in some standard format, such as HTML, DHIML, XHTML, XML. etc., in some ad-hoc 
strucnired text foimat, or not at alL The following segment ilhistrates a simple exanq>Ie of a JSP con^KmeaC 

10 <htin> 

<% if (Calendar.getInstance0.get(Calendar JVM_PM) = Calendar j\M) {%> 
Good Morning 
<% } else ( %> 
Good Afternoon 
15 <%}%> 
</html> 

The exan^le above shows a response page, which is intended to display either **Goo6 Morning** or *Xjood 
afternoon** depending on the moment when the request is received. The page itself contains several fixed tenqibfB 
20 text sections* and some JSP elements enclosed in **<%%>** brackets. 

A JSP coinpcment may be handled in application servers by various types of JSP For example, m • 

one embodnnent, the Java Server process 204 shown in Figure 3 may manage or act as die JSP "-^g^ Hie JSP 
engine delivers requests from a client to a JSP component and responses from the JSP con^sonent to die *>Ki"»! t The. 
semantic model underlying JSP components is that of a Servlet: a JSP con^nent desciibes how to cnain m 
25 response object from a request object for a given protocol, possibly creating and/or using in die process "m rr odicr 
objects. 

All JSP engines must support HTTP as a protocol for requests and responses, but an engine may also 
suppon additional request^esponse protocols. The default request and response objects are of type 
HtqpServletRequest and HttpServIetResponse. respectively. A JSP component may also indicate how some eventt 
30 are to be handled. In JSP 1.0, only init and destroy events can be described: the first time a request is delivered to a 
JSP component a jspInitQ method, if present, will be called to prepare the page. Similarly, a JSP engine can redaim 
the resources used by a JSP component at any time that a request is not being serviced by the JSP conqxment by 
invoking first its jspDestroyO method; this is the same life-cycle as that of Servlels. 

JSP components are often implemented using a JSP translation phase that is done only once» followed by 
33 some request processing phase that is done once per request The translation phase usuaDy creates a r'»*f that 
implements the javax.servleLServlet interface. The translation of a Ja> source page into a corresponding Java 
implementation class file by a JSP engine can occur at any time between initial deployment of the JSP component 
into the mntime environment of a JSP engine, and the receipt and processing of a client request for die target JSP 
con^onent A JSP component contains some declararions. some fixed template data, some tpcrhaps nested) action 
40 instances, and some scripting elements. When a request is delivered to a JSP component, all these pieces are used to 
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cieate a response object that is ihcn rcmrncd to the client. Usually, the most imponant pan of this response object b 
tihe result stream. 

A JSP component can create and/or access some Java objects when processing a request The JSP 
specification indicates that some objects are created in^licitJy, perhaps as a result of a directive; other objects axe 
5 created explicitly through actions; objects can also be created directly using scripting code, although this is less 
common. The created objects have a scope attribute dcfming where there is a reference to the object and when tfa^ 
reference is removed. 

The created objects may also be visible directly to the scr^ting elements through some scriptiag-kvcl 
variables (see Section 1.4.5, -Objects and Variables). Each action and declaration defines, as part of its semantics, 
10 what objects it defmes, with what scope attribute, and whether they arc available to the scripting elements. Objects 
are always created within some JSP component instance that is responding to some request object JSP defmes 
several scopes: 

- page - Objects with page scope are accessible only within the page where they arc created. AB references to such 
15 an object shall be released after the response is sent back to the client from the JSP component or the request is 

forwarded somewhere else. References to objects wiA page scope are stored in the pagecontcxt bisect 

- request - Objects with request scope are accessible from pages processing the same request where diey were 
created. AU references to the object shaU be released after the request is processed; in particular, if Ac request is 

20 fwwarded to a resource in the same runtime, the object is stiO reachable. References to objects wiA request scope 
are stored in die request object 

- session - Objects with session scope are accessible from pages processing requests diat are in die same sessim as 
die one in which they were created. It is not legal to define an object widi session scope from within a page Aat is 

25 not session-aware. All references to the object shaU be released after the associated session ends. References to 
objects with session scope are stored in the session object associated with the page activaticm. 

- application - Objects with application scope are accessible from pages processing requests that are in the same 
application as tiiey one in which they were created. AU references to the object shall be released when die runtime 

30 environment reclaims the ServlciContext Objects with application scope can be defined (and reached) from pages 
that are not session-aware. References to objects with application scope are stored in the appKcadon object 
associated with a page activation. A name should refer to a unique object at afl points in the execution, U. aO Oe 
different scopes rcafly should behave as a single name space. A JSP implementation may or not enforce fhis role 
explicitly due to performance reasons. 
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Fixed Template Data 

Fixed template data is used to describe those pieces that are to be used verbatim cither in the response or as 
input to JSP actions. For example, if Ac JSP component is creating a presentation in HTML of a list of. say. books 
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that match some search conditions, the template data may include things like the <u>,,<Ai>, and something like 
<li>Thc following book... , 

This fixed template data is wrinen (in lexical order) tinchanged onto ihe output stream (referenced by the 
in^licit out variable) of the response to the requesting cbcat 

5 . • 

. Directives and Actions 

JSP elements can be directives or actions. Directives provide global information that is conceptually valtfl 
independent of any specific request received by the JSP component For example, a directive can be used to 
indicate the scripting language to use in a JSP component Actions may, and often wiH depend on the details of the 
10 specific request received by the JSP component If a JSP is in^lemented using a compiler or translator, die 
directives can be seen as providing information for the compilation/translation phase, while actions are infonnatioo 
for the subsequent request processing phase. An action may create some objects and may make Aem available to 
the scripting elements through some scr^ting-specific variables. 
Directive elements have a syntnt of the foim 

15 <%@ directive ...%> 

There is also an alternative syntax that follows the XNfL syntax. 

Action elements follow the syntax of XML elements, Le. have a stait tag, a body and an end tag: 

<niytag atirl«"atiribute value"* —> 
body 
20 </niytag> 

or an entity tag 

<n]ytab attrl^'*atiribute value** ^J> 

A JSP clement has an element type describing its tag name, its valid attributes and its 
25 semantics; we refer to the type by its tag name. 

Applications and ScrvletCbntexts 

In JSP 1 .0 (and Servlet 2. 1) an HTIP protocol application is identified by a set of (possibly disjoint) URLs 
mapped to the resources therein. JSP 1.0 docs not include a mechanism to indicate tfiat a given URL denotes a JSP 
30 conqwnent. although every JSP in^lementation will likely have such mechanisnt For example, JSPs may be 
identified by a -.jsp" file extension. In most JSP implementations, a JSP component is transparently translated into 
a Servlet class file through a process involving a Java^ compiler. 

The URL set described above is associated, by the JSP engine (or Servlet runtxnac environment) with a 
unique instance of a javax^avlctServletContext Servlets and JSPs in the same application can share this instance, 
35 and they can share global application state by sharing objects via the ScrvletContext setAttributeO» getAttributeO 
and rcmovcAttributcO methods. We assume that the information that a JSP component uses directly is all 
accessible from its corresponding ServIetContext 

Each client (connectioii) may be assigned a session Oavax.servlcthttp JlttpScssion) uniquely identifying it 
Senrlets and JSPs in the same -application- may share global session dependent state by sharing objects via the 
40 Ht^ession putVahieQ, getVahieQ and removeVahieQ methods. Care must be taken when sfaaring/manipulatiQg 
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such state between JSPs and/or Servlcts since two or more threads of execution may be simultaneously active 
within Servlets and/or JSPs. thus proper synchronization of access to such shared state is requiied at aU times to 
avoid unpredictable behaviois. Note that sessions nay be invalidated or expire at any time. JSPs and Servlets. 
handling the same jaVax^leuSeryletRequest may pass shared state using the ServletReipiest setAtiribttteO. 
5 getAttributeOandrerooveAttTibuteOmedjods. 

Translation Phase 

A typical inrlcmcntation works by associating with the URL denoting the JSP a JSPEn^neSenrlet This 
JSPEngineServlet is responsible for determining if there already exists a JSP component irrrlementation class; if 
not it win create a Servlet source descrqition in^lementing the JSP conqwnent, c<Hiq>Oe it into some byieeodcs and 
then load them via a OassLoader instance; most likely never touching the file system, dice the JSP component 
implementation class is located, the JSPEngineServlet will perform the usual Servlet initialization and wfll deliver 
the reipiest it received to the instance. The JSPEngineServlet Servlet is instantiated in a ServletContext that 
i^iesents the original JSP object 
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ISP Response Caching 

•Ihis section describes how response caching may be enabled fa a system implementing JSP tedmology. 
AUbougb one use of JSP is to create dynamie responses, such as dynamic web pages for display, it wiD be 
appreciated that response caching may be desirable fai many simations. For example, data used to create a response 
ri»y change only once an hour, and thus a response created from the data could be cached and reused much of the 
time. In particular, caching may often ingwove the performance of running composite JSPs. diat is JSP fllea wliidi 
inctnde other JSPs. 

For each JSP convonent, the criteria for reusing a cached version of the response may be set, e^.. by 
inchiding a method caD in the JSP file, such as "setOicheQiteriaO-. The setCacheOriteriaO method may be 
overloaded to allow for various arguments to be passed in. to one embodiment the setCacheOriteriaO method 
canq>rises the following signature variants: 

setCacheCiiteiia(int sees) 

where the 'sees' parameter indicates the number of seconds for which the cached response should be considered 
vaKd. to this variant, no other criteria are specified. Thus, the JSP response is unconditionally cached. If W is 
set to 0. die cache may be flushed. 



setCacheCriteria(int sees. String criteria) 

where the 'sees' parameter is die same as described above, and the 'criteria' parameter specifies die criteria to use 
35 in determining whether or not the cached response may be used to satisfy a request Caching criteria »e discussed 
in more detail below. 

sctCachcCritcria(uit sees, int size. Siring criteria) 
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where ihc *secs* and 'criteria* parameters arc ihc same as described above, and <hc *si2e* parameter specifies the 
size of the bufler for the cached response. 

Caching Criteria 

5 The interface for calling JSPs is based on the interface javax^ervlet J^equestDispatcher. This interface has 

two methods, forvardQ and inchideQ, where the former acts like a redirect, i.e. it can be called only once per 
request, whereas the latter can be called multiple times. For example, a forward call to f jsp' may look like: 

public void scrvice(HttpScrvletRcquest req, HttpServlctRcsponse res) 
10 throws ServletException, lOException 

^ resjetContcritType("tcxt/htnnI"): 
RequestDispatcher dispatcher » 

getServletContext0.getRequestDispatcher('*fjsp*); 
15 dispatcher.forward(req,R3); 

) 

JSP coinponenis often accept and use arguments themselves. Arguments to the JSP lile can be passed as part of the 
URL of the file, or in atvibutes using ServlctRequest-setAttribmeO- These argument names and vahies can be used 
20 to set caching criteria and to check whether a cached response can be used to satisfy a requoL 
For exarxiple, in an include call to Tjsp\ arguments 'age' and 'occupation' can be pas^ 

public void service(HnpServlctRcquest req, HttjpServletResponse les) 
throws ServletExceptiOD, lOExceptim 

25 { 

res.sctO>ntentType(*text/btmr); 
RequestDispatcher dispatcher * 

getSeivlctContcxt0.gctRcqucstDispatchei(''fjsp?age-42''); 
req.setAttribute(*'occupation'',*doctor^; 
30 diq^tcherJnclude(req, res); 

) 

Within the f jsp component, a sctCachcCriicriaO statement may then set the response caching criteria based on the 
vahies of the 'age* and •occupation' arguments. For example, the f.jsp component may include the statement: 



35 



<% setCacheCriteria (3600, •'age>40 & occupation^doctoO; 



to indicate that the response should be cached with an expiration time of 3600 seconds, and diat die response may 
be used to satisfy any requests to run the f.jsp conqf>onent with an 'age' argument value of greater than 40 and an 
40 *occupadon' argiunent value of "doctor^. 

Of course, the JSP component may contain numerous setCacheCritcriaQ statements at different points in 
the JSP file, e,g. at different branches within an 'iT statement, each of which may set different caching criteria. 
Depending on the arguments passed in to the JSP and other dynamic conditions, a particular set of caching criteria 
45 may then be set for the response currently being generated. 
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In the example above, the dispatcher may use the values of the 'age* and ^occupation* arguments to 
determine whether any cached JSP responses can be used to satisfy a request instead of re-running the JSP and re- 
generating a response from it For example, a request to f.jsp appearing as: 

5 res^ctContentTypc('text/httnl*); 

RequestDispatcher dispatcher » 

getScrvleiContcxt0.getRcqucstDispatcher("f.jsp?age«39&occupation«doctor*); 
dispatcher.forward(req, res); 

10 would not be satisfied by a response previously generated from the f.jsp JSP which haid set its caching criteria widi 
tfte statciucnt: 

<% setCachcCriteria (3600, •^agO*© & occupatioii=doctor): %> 

15 because the age argument is not within the range specified as valid for this cached response. However, this same 
request may be satisfied by a response previously generated from the f.jsp JSP which had set its caching criteria 
widi the statement: 
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<% setCacheCriteria (3600, "age>35 & occupation=«doctoO; %> 



Hence the cache may be checked before running a JSP, and if a valid cached response is foimd, then the ^spatcfacr 
may return the response tmmediatBly. 

A cached JSP response may be stared in various ways. In one embodiment, a response is stored as a byte 
anay (bytcD w Java). Each cached response may have an associated criteria set stored, indicating when die 

25 response is valid. The criteria may include an expiration time, e.g. a time in secoiids to consider the cached 
response valid. After this expiration time passes, die response may be removed firom the cache. The criteria may 
also inchide a set of constraints, where each constraint specifies a variable and indicates the valid values vAudk die 
variable vahic must match in order to satisfy the cache criteria. As described above, a JSP le^wnse may set dwse 
cache criteria programmadcally using a seiCachcCriteriaO statement For exan^le, the SetCacheCriteria (3600, 

30 '•ag035 & occupation=doctor'0 statement appearing above specifies an expiration time of 3600 seconds and a 
constraint set with two constrainls: 

*age*>35and 
•occupation' « "doctoi^ 



In various embodiments^ different types of constraints may be specified, including the following types of 
constraints: 



_ X (e.g., SetCacheCriteria (3600, •*x*)) 

40 meaning that ^x' must be present either as a parameter or an atoibute. 
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- X = vl I v2 1 ^ I vk (e.g^ SetCacheCriteria (3600» '^'=docioijnuise'0) 

meaning that *x* must match one of the strings listed For each string* a regular cxpressioD may be used, where *x* 
is said to match the string if it meets the regular expression criteria given. 

5 -x = low 'high (eg., SetCacheCriteria (3600, •^=20 - 50")) 

meaning that *x' must match a vahie in the range of low <*> x high. 

Various other types of constraints may also be specified, such as the use of mathematical **greatcr than/less ihttnT 
symbols, etc. for ensuring that an argtmient falls within a certain range. Also, constraints may be speciAed based 
10 on dynamic user session data, such as the current value of a user's shopping cart, user demographic informatioii. 

Figure 19 - Flowchart 

Figure 19 is a flowchart diagram illustrating one embodiment of a method for enabling JSP response 
15 caching, based on the above description. In one embodintent, the JSP engine manages the ptocc&s .iOustrated in 
Figure 19. 

In step 600 a request referencing a JSP component is received. The request may, for example,, have an 
associated URL that rcfcicnccs a JSP. The JSP engine may receive the request from another service or co m po n ent 
numing on the application server or directly from a client computer. 

20 In step 602 the JSP response cache is checked to determine whether a response in Ibe cache satisfies die 

request The JSP response cache may be implemented in any <»f various ways, and responses and their associated 
criteria sets may be repiesented and stored in the cache in any of various ways. As noted above, in one 
embodiment, a response is stored as a byte array. 

As described above, the information received along with the JSP request may include various attributes, 

25 such as variable name value pairs. In step 602, these attributes may be compared against the criteria set for each 
cached response. The con^arisons may be performed in various ways, depending on what' types of matdiing 
criteria are supported in a pardcular embodiment and how the criteria are stored. The JSP respo n se cache is 
preferably organized to enable an eflicicnt criteria-matching algorithm. For example, the cache may be organized 
based on session context such as user ID or role, secnirity context, etc 

30 In step 604 it is determined whether a matching cached response was found in step 602. If so, then in stq> 

606 the cached response is immediately returned without running the referenced JSP. For exan^Ie, if responses are 
stored as byte arrays, then the byte array corresponding to the response whose criteria set matched the request 
attributes may be retrieved and streamed bade. 

If no matching cached response was found, then in step 608 the referenced JSP may be called. The JSP 

35 engine then executes the JSP, using the attributes included in the request As described above, depending on the 
dynamic conditions of the execution, diflerent SetCacbeCriteriaO method calls widi different argitunents may be 
encotmtered during the JSP execution. 

In step 610 it is determined whether the JSP response should be ca che d. Tor example, if no 
SetCacheCriteriaO method calls were encountered during the execution of the JSP, then the response may not be 
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cached. Also, in various embodiments, the application server may enable adxniiistratois to utilize a user interface 
to specify for which appKcation server components the ouqaut should be cached This information may. also be 
checked in step 610. 

If the JSP response should not be cached, then the response may simply be renimed in step 616, c.g^ by 

streaming back the response. 

If the JSP response should be cached, then in step 612 a response entry to represent the response may be 
created, and in step 614 the JSP response may be stored in the response entry. As noted above, response entries 
may be implemented in any of various ways. As shown in step 612, the a^wopriate criteria set, as defmed by die 
arguments of the SetdcheCritcriaQ method caDs encountered during the JSP execufion may be associated with die 
response entry. Note diat, if multiple SetCacheCriteriaQ method calb are encountered, then multiple response 
entries corresponding to the method calls may be created. 

In step 616 the JSP response is then rctunMd. 

It is noted that Figure 19 represents one embodiment of a method for enabling JSP response caching, and 
various steps may be added, omined, combined, modified, reordered, etc. For example, in one embodimeni, m step 
may be added so that die JSP file referenced by the request is checked on the file system to determine whe&cr ttie 
lOe has been modified smce the JSP was loaded or since the associated responses were cadied. If so, ih^ associaied 
responses may be flushed ftom the cache, and the JSP may be reloaded and called. 

Composite JSPs 

Wifli the support described above, composite JSPs. that is JSP files whidi inchide odier JSPs. can be 
efficiently implemented. TTicre may be one uip-level frame, emitted either fiom a seivlet ^ 
issues one or several RequestDispatcherJnchide calls for other JSP files. Each of the inchidcd JSP files 
generate response content Some of these JSP files may aheady have associated responses cached, and othen may 
not. For each cached response time, the associated expiration time may vary. 

For example, here is a *compose.jsp* JSP listing: 



<% setCacheOitcria(l); %> 
<inML> 

30 <HEAI» 

<rrrLE>conqK>se (JSP)<;/TriXE> 

</HEAD> 
<BODY> 

<H2>Channel 1</H2> 

35 

RequestDispatcher disp « 

getServlctContcxtO.gctRcquestDispatchexCcl.jsp"); 

disp.include(request, response); 
%> 

40 <H2>Channel2</H2> 
<% 

disp « gctScrvletContcxt0.gctRcquestDispatchcrCc2,jsp"); 
disp.include(request, response); 
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%> 

</BODY> 
</HTML> 



5 where *ctjsp' appeals as: 



<% setCacheCnteTia(10); %> 
<kil> 

<li>Today 



</u> 

and 'c2.jsp' appears as: 



15 <% sctCacheCriieria(2,'x"); %> 
<li>Toiiionow ... 



Note that neither *c 1 jsp* nor *c2.jsp* emits coiiq>lete HTML pages, but radier snqipets ibereof, and tfiat each file has 
its own caching ciiteria. 

A helper function for including URIs may be provided* so that, for example, the above*listed 'con^pose.jsp* file 
25 may appear as: 

<% setCacheCriteria(l); %> 

<HTML> 

.<HEAD> 

30 <TTnJE>conipose (JSP)</TITIJE> 
</HEAD> 
<BODY> 

<H2>Cbamiei KH2> 
<% 

35 includeURI("cl.j5p'*;request,response); 
%> 

<H2>Channel 2<;«2> 
<% 

includeURI(*c2.jsp'*^quest. response); 
40 %> 

<mODY> 
</HTML> 



instead of as the listing shown above. 
Events 

In various embodiments of application servers, developers can create and use named events. The 
event is widely used to refer to user interface actions, such as mouse dicks, that trigger code. However, the events 
described in this section are not user interface events. Rather, an event is a named action or set of actions that may 
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. TK^ ^v*.nt mav be ttifigercd either ai a specified time or may be activated 

Tf^pisicred with the application seivcr. The event may oc oiBgc. r 

«j- ^i..*»»v<:^eo load balaiiciiift,TCSuh-cachiiig, etc 
called in other ways, e.g, loaa inuauwiH^ -rhi« mav he a sei>araticm. 

An input lis. .cfcned «, .s . ValList nuiy be pa«cd » tnggcrcd evcn«. "^"^1^^ 
^ tir^^KlAcdousofanevcat T«s ValUs. con^riscs c»mcs describing Anributcs. Each acuoa of 

events. c.apanic«l«cv«..mayb. configured tohave.ch«t«.widcsca^ 
event sefvice, events, or 8 parocuiwe h / ^. Eadi event may have associated 

30 tobeacr«e4-nd,egiste«afo..vetysen,e,intbec,us«^tne«U*^ 

atrtmte. speciiying ..hicb appKcadon setvcr even, should nm «m load balanang cntena. 

wefeiably stored persistently. e.g. in a registry or a database. 

I one onbodin^nt. events n.y be registered by any application server en^at^^^ 

lication sen^er engine. Events n«y be registered on n^ultiple application servers. In one «nbodnnent. even^ 
^.canon s«v« cng ^ ^ ^ ^^^^ servers « a s»g,e 

35 operations such as regisnatjon. aooing arolication servers. For ewniple, m 

operation. i.e. .be even. API nu.y suppon even. nuu»gen.ent aaos. rnult^e applK^ 
eLn«ybecreatedfro«oneapplicaUonsen.er«.dd«ncal.edftom-r.o*erappl«tu»s™^ 
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Event API 

This section discusses one embodiment of an API for managing and using events. 

To create a new event, use the following procedure: 
5 1. Obtain the event manager object by calling geiAppEvent( ). For example: 

lAppEvcnt evcntMgr « getAppEvemO; 

2. Specify the characteristics of the new event by setting up an IValList object with a set of vahies, each one being 
one characteristic of ihe event. The vahies required in this object vary depending on whether the event's action is to 

10 nm an application component, send an emaflt etc 

3. Infonn the application server of die new event by calling regisierEveiit( ). 
For example, the following code sets up an event to send email: 

15 

IValList eventOutput; 
IValList eventlnput2 GX.CreateVaIListO; 
String cventName2 » TleportEvent"; 
// Add the ReportAgent iqspevent name to the vallist 
20 evcntInput2^etValString(GX.AEJlE_KEYJ^AME.GX.AE.^ 
eventNanBe2); 

// Set the appevent state to be enabled 

evcntlnpua^tVaUnt(GX_AE_RE_KEY_STAmOX.AE.RE_KEY_CTA're» 
GX_AE_ltE.ESjaj\G.GX_AE_RE.EVEOTlENABIJED); 
25 //Set the appevent time to be 06:00:00 his everyday 

eventInput2^tValString(GX_AE.RE_KEY_TIME:GX,AEJRE_KE^ 

•6:0.-0 •/•/•"); 

// Set the appevent action to send e*mail to 
// report@acme.com 

30 evenllnpul2.setValString(GX.AE_RE_KEY.MTO;GX_AE_RE.KEY_^^ 
"ieport@acine.com"); 

// The content of the e-mail is in /tnqi/repoit-file 
eventlnput2jsetValString( 

GX_AE_RE.KEY.MF1LE.GX_AE.RE.KEY.MF1LE, 
35 -/trop/rcpon-file"); 

// The e-mail host running the SMTP server is mailsvr 
eventInput2^etValString( 

GX.AE_RE_KEY.MH0ST.GX_AE_RE_KEY_MHOST. 
"mailsvr.&cme.com"); 
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// The sender's c-mail address is admiii@acine.cam 
cvcntInput2.sctValStriiig( 

GX_AE_RE_KEY.SADDR.GX_AE.RE.KEY„SADDR. 

"adiniD@acme.com"); 
//Register die event 

if (cvcntMgrjc£istcrEvciit(evcntNamc2, eventlnputl) 
!«GXE^CCESS) 

return strcaroRe$ult("Can not register RcportEvent<br>"); 



Triggering an existing event: 

TypicaUy. an event is triggered at time intervals which you specify when you create the event. You can 
also trigger the event at any time from code. The event still occurs at its timed intervals also. Those events that do 
not have a timer arc triggered only when called from code. 

To trigger an event: 

I. Obtain the event manager object by calling gctAppEvenl(). Forexaople: 
lAppEvent evenlMgr - getAppEvcutO; 

20 2. Ifyou want to change any ofthe characteristics oftheevem before nnming^ 

desired characteristics. Use the same techniques as you did when setting up the event, but include only those 
characteristics yon warn to override. For exanqile: 
IValList ne««*rops « GX-CreateVallistO; 

ncwPr0ps:setValString(GX.AEJlE.KEY_NREQ.GX.AEJlE^^ 
25 -RunReportV2"); 

3. To trigger the event, call setEvent(). For example: 
eventMgr-setEvent("RcponEvent*,0,newPiops); 
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Deleting an event: 

Delete an evem when the event and its actions are not meaningM anymore^ 
only during the lifetime of an application conqNment execution. 



3S To delete an event: 

1. Obtain the event manager object by calling getApp£vent( ). For exampU: 

lAppEvent evcniMgr = getAppEveniO; 

2. To delete the event permanently. caU deletcEvcnt( ). For exanq^le: 
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Temporarily disabling an event 

Disable an event if you donU want ii to be triggered during a tempoxary period. For example, you miglit 

not want to generate reports during a company holiday. 
To disable and enable an event 

1. ObtainthccventmanageiobjcctbycallingBCtAppEventO. For example: . 
lAppEvent evcntMgr = geiAppEveniO; 

2. To stop the event Immnnming temporarily, caUdi^^^ 
eventMgr.disablcEvent(TleportEvenl^; 

3 When you want the event to be available again. caU enableEvent( ). For examples 
eventMgr.enableEvent("ReponEvenr); 



Getting infomiation about events 

To get infomation about a particular event. caU q»cryEvent( )- Tto method the IVaIL«t ol,cct 

U«t contains thtchaiacteiisdcs of .he event. To get complete details about all the currently defined «v««,. fi«t 
can enumEvcnt^ ). TOs nKdu.d rennns the WalList objects of an the events known to the appteition server. Tl«. 
can en«nNe«( ) u> step through the IValUst o^ecu returned by e«un.Ev««( ). enuniE^ ) -«* 
^^y^K )«cthods are defined in the lAppEvcnt interfece. e««niN««( ) OKthod is defined » d« 
lEimmObject interface. 
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Exan^le: 

The following code generates a repon of all registered events. 

// Open /tmp/report-file for writing the repent 

FileOutputStrcani outFile = null; 
5 outFile new FileOutputStreamC'/irap/rcpoTt-filc*); 

ObjectOu^utStrearo p = null; 

p = new ObjertOutputStrcam{oulFflc); 

// get appevent manager 

lAppEvent appEvcnt = gctAppEvcntO; 
10 // Get the Emmieradon object containing ValLists for all 

// the registered events 

lEnumObject enuraObj - appEvenLcnmnEvcntsO; 
//Retrieve the count of registered appevents 
int count enuinObj.ciiuniCountO; 
15 p. wriicObjcctCT^unibcr of Registered Events: "); 
p.writeInt(count); 
cminiOb|.cnuiDReset(0); 
while (count >0) { 

lObject vlistOIri » enumObj-enumKextO; 
20 lVaIListvList«(IVa]List)vIJstOiig; 
String name * 

vIJsLgciValString(GX.AE_REJCEYJ4AME.GX_AEJUB_KEy 

p.writeObjcctC'NnDelinitions for AppEvcnt named •); 

p.writeObject(nanie); 

25 p.writeObjectOB"); 

// Reset the next item to retrieve from ValUst to be 

// the first one 

vUstJcsciPositionO;// Iterate through all the items in the vallist and 
//print them 

30 while ((name « vListgetNexdCeyO) J»II) ( 
GXVALval; 

val » vList-getValByReflnanie); 
p.writeObjectCVnM"); 
p.writeObjcct(namc); 
35 p.wriicObjcct(" 

p.writeObject(vaLtoStringO); 

} 
} 
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Example interface for event API: 

interface IGXAppEvcntMgr '{ 
HRESULT CreateEvent( 
5 [inj LPSTR pEventNamc, 

[out] IGXAppEventObj **appeventObj 

); 

HRESULT RcgisicrEvcnl( 

[inJ IGXAppEvcDtObj* appEvcntObj 

10 ); 

HRESULT GetEvenK 

[in) LPSTR pEvcntNaxnc, 

[out] IGXAppEvcntObj ••pAppEvent 

15 ); 

HRESULT TriggerEvcntt 
[in] LPSTR pEventName, 
[in] JGXValList •pInValList. 
20 [m]BOOLsyncFteg 

); * 

HRESULT Enable£vcnl( 
[in] LPSIR pEventNaiw 

25 ); 

HRESULT I>isableEvcnt( 
[in] LPSIR pEvcntName 

30 

HRESULT DelcteEvcnl( 
[in] LPSTR pEventName 

); 

35 HRESULT EnuinEvents( 

[out] IGXEnumObject **ppEveats 

); 

) 

40 Descripiions: 



OieateEvent 

pEventName: name of the event to be registered. 
appcvcntObj: pointer to returocd appcvcnt object. 
45 CreateEvent creates a cxtspty appevent object Attributes and Actions can be set on the returned a|^)evenfObj, and 
then registered with AppEventMgr using RegisterEveiiL Note that changes to appeventObj do not take effect until it 
is registered with die Manager: 



RegisterEvent 

50 appeventObj: pointer to appevent object that is to be registered. 
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Registers a appevent object whose attributes and actions have been setup. AB changes to appEventObj aie 
commitied to the server, and the registry. If an appevent object already exists for the given name, then that object is 
deleted and this new object will take its place. 

5 GctEvest 

pEventNane: name of the event 

appeventObj: pointer to returned appevent object 

GetEvent retrieves a appevent object for a given event name. 

10 TriggerEvent 

pEventNamc: name of the event to be triggered. 
pValLisu input ValList that is passed to Actions. 

syncFlag: boolean flag to denote if event is to be triggered synchronously. 

Triggers a specified appevent A copy of plnVaHist is passed as input to aU actions registered wiA the appevent 



15 
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If the Action is an applogic, then pInValList is passed as input to that applogtc 
Uthe action is a mail, then plnVaUist is cunrenily an^ly ignore 

If die action is a Scrvlet, then the ennies of the input vallist are available as attributes of ServletRequest object Hiit 
is passed to the Servlet 

If syncFlag is FALSE, then the event is triggered, and the caU immediately retoxns without waiting for die actins 
to complete execution. If the flag is TRUE, then this call blocks until the event is triggered and aD actions aie 
executed. 

Actions are triggered exactly in the order they have been added to the appevent object 
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EnableEvem 

pEventName: name of the event 
Enables a appevent 

30 

DisableEvcat 

pEveniName: name of the event 
Disables a appevent 

35 DcletcEvent 

pEventName: name of the event 

Delete a appevent from the system and the regisny. 



EnumEvcnts 
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ppEvcnts: pointer to rciurned enuin object 

Enumerates all appevents that are registered with the server. Each element of the returned Enum object contains a 
appcvcnt object (of type IGXAppEventObj). 



5 interface IGXAppEventObj { 

. HRESULTGetName( 

(out, si2e_i5(nName)J LPSTR pNanie» 
[in, defat5i_vahic(256)l ULONG nName 

10 ); " 

HRESULT SetAttributes( 
[in] IGXValList* attrlJsi 

); 

15 HRESULT GetAttributcs( 

[out] IGXValList** attdist 

); 

HRESULT AddAction( 
20 [in] IGXValList* action 

); 

HRESULT DeleteActiQDS( 

); 

25 

HRESULT £aumActions( 

[out] IGXEnimiObiect** actions 

>^ 

30 J; 

G^Namc 

pName: pointer to a input buffer. 
nName: size of input buffer. 
35 Gets the name of the appevent. The name is set when the object is created .with CreateEventO- 



SetAttributes. 

attrList: input attribute vaOisL 

Sets the attribute ValList of the appevenL Note that chabges to an appevent object arc not ronnnitted until it is 
40 registered widi the AppEventMgr. • 



GctAttributBS 

attrList: pointer to returned attribute vallisL 
Gets the attribute vallist of a appevent. 

45 

AddAction 

action: input action vallisL 
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AddAction appends an action to a ordered list of actions. When an event is triggered, the actions arc executed 

exactly in the order they have been added. ValList entries describe the action being added, and vary from one type 

to another. 

5 DekteActions 

Delete all actions added to this appevent object 

EnmnActxons 

actions: pointer to returned enum object 
10 Enumerates actions added to. this appevent object Each entry in the returned enum object is a action vallist of type 
IGXValiist 

Sample portion of regisHy: 

6 EVENTS2 0 

15 7 tstEvl 0 

0 EnaUe 4 1 

0 ActionMode 4 1 

0 Time 1 • :0.1 0^030,40^0:0 •/•/• 

0 ActionCount 4 4 

20 8 1 0 

0 Sequence 4 1 

0 NcwReq 1 GUIDGX-{754CE8F7-8B7A.153F-O«B^800207B8777} 

8 2 0 

0 Seqoaiee 4 2 

25 O ServletReq 1 HenoWor]dScrvlet?argl<=vall&aigii2-'valii2 

8 3 0 

0 Sequcaee 4 3 

0 MailHle 1 Ai^chinta/appcvjnafl 

0 ScnderAddr 1 rchista 

30 0 MailHost 1 nsmail-2 

0 ToList 1 rchinta 

8 4 0 

0 Sequence 4 4 

0 NewReq 1 GUIDGX-{754CE8F7.8B7A-153F-C38B-0800207B8777} 

35 7 tstEv2 0 

0 Enable 4 1 

0 Time 1 •:8:0*/*/* 

0 ActionCottDt 4 1 

8 10 

40 0 Sequenee 4 1 

0 NewReq 1 GUnXjX-{754CE8r7-8B7A-l53F-C38B-0800207B8777}?pl-hello0 



Request Stepe 

45 In various embodiments, an application server may handle requests using a workflow model of defimqg a 

series of steps for each type of request As a simple txampU^ consider the ai^licatioD server architecture shown m 
Figure 3, in which a request of four steps is processed The first step may be to determine the appropriate entity to 
handle the request For example, the executive server 202 may broker a request to the Java server 204 if the request 
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references a Java™ component, or to the 00++ server 206 if the request references a C++ component, etc At 
another level, the Java server 204 may determine which Java^ component should handle a request. Thus, request 
steps may have different meanings in different contexts. 

Continuing the example, the second step may be to load the entity found in step 1 above. For example, die 
5 Java server 204 engine may instantiate the appropriate Java"™ object Some steps may not apply in certain contexts. 
For example, step 2 may not apply to an executive server-level request, since the appropriate scrvci pr process to 
hand ofT a request to is probably already running. 

The third step may be to **run** the entity using the request context, e.g. request parametexs. For exanqile, 
this run step for the executive server may mean to send the request data to the Java server and await the resuhs. For 
10 the Java server, this run step may mean to run the. Java''^ component on the Java™ virtual machine. 

The fourth step may be to stream back the results generated in the third step to the originating requestor. 
Diiferent step lists may be defined for each type of request. For example, the step list for a request 
referencing an Enterprise JavaBean™ may be different from the step liist for a request referencing a Java*** Seivlet. 

This method of rei^esenting requests as a series of steps provides advantages such as die flexibiliiy of 
15 weaving steps in any way desired for a given level; Also, steps may be easQy added into die step list For ^gwyl^t 
while traditional programmiiag models may require code to be reconipiled or reloaded m order to ahcr veqiicst 
• logic, the step model allows a new step to simply be added. 

Request Queneing 

20 Each request received from clients such as web servers may be packaged in a data packet having a 

particular format According to this format, a field in the data packet may specify a sub-protocoL This sub- 
protocol may specify whidi step list to use for die request 

A request manager service and queue and thread managers are discussed above with reference toiPiguie 4. 
If a request needs to be queued, for exanq^le if all the request-handling threads are busy processing requests, then 

25 the request may be placed into different queues based on the type of request A thread pool may be associated widi 
each request queue. Threads in different thread pools may have different characteristics. For example, requests 
requiring XA behavior, as defined 1^ the XA standard protocol, may be placed in a request qtieue that bas an 
associated thread pool comprising XA-enabled threads. If at some point whfle a request is being processed it is 
determined that the request needs to be handled by a different thread, then the request may be re-queued in die 

30 appropriate queue. For example, if a oon*XA*enab]ed thread is processing a request, and die application logic 
determines that the request now requires XA behavior, then the request may be requeued into a request queue with 
an associated thread pool comprising XA-enabled threads. Optimizations are preferably performed so that Ifae 
. request does not have to repeat the entire overhead of being taken from the network stack, unmarshaled, etc 

35 LogEing Facfllty 

In various embodiments, the application server may provide a robust, flexible logging facility, as described 
in this section. When logging is enabled, messages generated by application-level and system-level services may 
be logged. These messages describe the events that occur while a service or application is running. For exanqile. 
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each dmc the server communicates with a database, the logging facility may record the resulting messages 
generated by a database access service. 

Determining Types of M essages to Log 
5 Various types of messages may be logged.' In one embodiment, messages arc categorized into the foDoWing types: 

• Information message. Describes the processing of a request or normal service activity, such as a status update. 

• Warning message. Describes a non-critical problem that might be an indication to a Lirger problem. For 
cxan^lc. when a service is unable to connect to a process, a warning message may be logged. 

10 • Error message. Describes a critical faihire of a service, from which recovery is not likely. For example, when 
a service encounters a critical problem, such as a pipe closure. 

A user interface may be provided to manage message logging. e.g..enabling/disabling logging, specifying 
the types of messages to log. etc. An example of a user interface to manage message logging is shown in Figure 20. 
15 hi Figure 20, the Maximum Entries field specifies the maximum number of entries that can exist before datm is 
wrinen to the log. The Write hiterval field specifies the amount of time (in seconds) tiiat elapses before date is 
written to the log. The Message Type field specifies which types of messages shouM be logged (informational 
messages, warnings, and/or errors.) 

20 Log Message Format 

In one embodiment, log messages has the following four components: 

• date and time the message was created 

• message type, such as information, warning, or enor 

• service or application component ID generating message 

25 • message text 

Logging Destination 

n.e logging service can prefeiably be configured to record saver and appUcation messages in any « aD of Ihe 
following destinations: 

Process consoles. By de&uH. the process consoles may display log messages as they are geiwated. If logging 
is enabled and the sava is enabled for automatic startup (UNIX) or interaction with dte desktop (NT), die 
consoles open and display the log messages. Hiis feature can be disbaled by deselectiiig d»e Log to Console 
checkbox. 

Application log. The default application log file. For Windows NT. this may be viewable through the Event 
Viewer. This is the default Provides a more comprehensive record of the server and appBeatioB enor 
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messages. Warning and infonnation messages are not logged to the application log. AU messages are sorted by 
their tisnestamp. 

• ASCII text file. An ASCII text file, which the user can create and specify. Used for a more permanent record 
5 of the server and application messages. All messages are soned by their timestanq>. 

• Database table. A database table which can be created and specified. This may be the most versatile logging 
destination and can be used when it is desired to sort, group, and create reports of the logged messages. 

10 In one embodiment, the server may use a log buffer to store messages before they are written to die 

application log. an ASCO file, and/or database logs. This buffer optimizes the performance of the i^lication server 
by limitiDg the use of resources to continually update a log. The buffer is wrinen to the destination when eidier the 
buffer interval times out or the number of entries in the buffer exceeds the maxinwm number allowed. 

15 The following messages sent to an ASOI text file iUustrate exemplary forinais of text m^^ 
[11/18/97 1 1:1 1:12:01 info (1): GMS-017: server shutdown (host 
OxcOaSOlae, port 10818, group •MB') - updated host database 

(l 1/18/97 1 1:1 1:18:2] warning (1): GMS-019: duplicate server (host 
20 0xc0a8017f, pon 10818) recognized, please contact sales representative for additional licenses 

Logging to a Database 

If messages are to be logged to a database, an event log database table may be created, i^igure 21 iUnstrates an 
exemplaiy type of database table for logging messages. On some systems, supplied scripts may be used for 
25 automatically setting up database tables. The application server logging service may map the message elements to 
die database fields listed in the table. 

File Rotation 

As shown in Figure 20, the application server logging facility may be configured to rotate ASCD log Hies 
30 at scheduled time intervals. When a log file is rotated, the existing log file may be closed and moved to an archive 
location, and a new log file may be created for recording further log events. Since log files are stamped wiOk die 
time and date they are created, log file rotation helps organize log files into manageable tmits. The times at ^*ich 
the log fdes should be rotated may be specified using a regular time interval, as ilhistrated in Figure 20, at using a 
string expression, e.g., by typing a string into the field shown. In one embodiment, a string expression should be of 
35 the format: 

hhonmiss W/DD/MM 

where the following table explains each clement of die expression: 
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Element Explanation Possible Values 

hh hour of the day 0-23 

miD minute 0-59 

5 ss seconds 0-59 

W day of the week 0 - 6 (0 for Sunday) 

DD dayofthemondi 1-31 

MM month 1-12 

10 Each of these fields may be either an asterisk or a list of elements separated by commas. An clement is 

either a nuinber or two numbers separated by a minus sign» indicating an inclusive range. An asterisk specifies all 
lejgal values for that field. For cxanq>]e, the cxpressicm: 
2,5-7:O:0 5/»/* 

specifies that logging should be rotated at 2:00am, 5:00am, 6 lOOaro and 7:00am every Friday. The specificatian of 
15 days can be made by two fields: day of the month (DD) and day of the week (W). If both are specified, then both 
may take effect ' For exan^e. &e expression: 
IHlKlUlSr 

specifies that logging to a new file starts at 1:00am every Monday, as well as on the fifteenlh of each mondi. To 
specify days by only one field, the other field may be set to ' 

20 

In one embodiment, the following environment entries, which may be in^lemented as registry entries, are provided 
to manage log file rotation. A user interface such as shown in Figure 20 may be provided to set these entries. 

• EnableRotation: Log file rotation will be enabled when set to "*!**, or disabled when set to "H)**. By default, log 
file rotation is disabled, 

25 • Rotatellme: An expression string denoting the time at which the log file is to be rotated. 

• TextPadi: In one embodiment, when log fDe rotation is not enabled, the name of each log file is based oo die 
value of the TextPath entry, plus the process ID of the logging process. When log file rotation is enabled, the 
name of each log file is based on the value of the TextPath entry, phis the process ID, phis the time at which 
the fDe is created. A fDe name may be of the format <rextPath>_<process-id>_<timc-CTeated>, where 

30 <TcxtPaili> is the value of the TextPath entry, <process-i^ is the id of the logging process, and <tiine- 

created is the time at which logging to the file started. 

Logging Web Server Requests 

The apph'cation server may be configured to log web server requests. For exazrq>le, a web server plug-in 
35 such as shown in Figure 4 may send requests to the application server where they are processed. By logging wd> 
server requests, request patterns and other in^ortant request information may be tracked. 

Web server requests may include HTTP requests. A web seiver HTTP request may be divided into 
standardized HTTP variables used by the web server to manage requests. The application server may include dicse 
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or a subset of these HTTP variables to be logged. Variables may be added to the list if additional log information is 
desired. In one embodiment, each HTTP variable is mapped to a field name in a database table. Figure 22 
illustrates an exemplary type of database table for logging web server requests. On some systems, supplied scripts 
may be used for automatically setting up such a table. 
5 Note that Figure 22 illustrates a field name of "^logtime** in the database table. The applicatioD server 

logging service may record the time that the message is created in the logtime database field. Note that database 
field name may be renamed. The fields fi-om the database table may be automatically mapped to web server 
variables in the registry.. 

10 Out of Storage Space ConditiOB 

One problem that is not handled well, or not handled at all, by many application server logging facilities is 
an out-of-storage-space condition, such as an out-of-disk-space condition. Since many odier logging facilities do 
not handle an out-of-stofagc»space condition gracefully, this condition causes many odier application servers to &fl, 
e.g. by crashing. 

15 Thus, when running out of storage space, the application server may automatically 'suai>end logging tmtfl 

more storage space becomes available. Logging may then resume when storage space becomes available. In one 
embodiment, it is guaranteed that when the application server suspends logging for lack of storage space, a message 
to that effect will be written to the log file. The applicatioii server logging facility may reserve a certain amoimt of 
disk space to write such a message if necessary. The logging facility may suspjcnd l«>gging for die duratian of tihe 

20 out-of-storage space condition, and then automadcaBy resume logging when the conditioii is co lle ct e d. Hie 
appHcaition server logging facility may monitor the amount of available storage space, eg. via a task that wakes 
periodically and performs diis chedL 

Figure 23 is a fiowchart diagram illtxstrating one embodiment of a method for handling out-of-slorage- 
space conditions. As shown, in step 500, an amount of storage space may be reserved, e.g., at die startup time of 

25 the logging service. This storage space may be disk space or anodier type of media storage space,' depending on 
where messages are logged. The amotmt of storage space reserved may vary, but is prefctably a relatively smaO 
amount suitable for logging an out-of-storage space condidon message, as described belofw. The storage space nay 
be reserved in any of various ways, depending on the particular operating system, programming language, eld. 

As shown in steps 502 and 504, the amoimt of storage space currently available may be chedced 

30 periodically. For example, the logging service may create a thread that wakes up periodically and performs diis 

If an out-of-storage-space condition is detected, then message logging may be suspended, as shown in 8tq> 
506. In one embodiment, the logging service may simply ignore requests by clieiit processes to log messages while 
message logging is suspended. The logging service may return an cnor code to die client indicating diat the 
35 message was not logged. 

In step 508, a message indicating the out-of-storagc-space condition may be logged, using die storage 
space reserved in step 500. In various embodiments, other actions may also be taken in response to an oUMf" 
storage space condition. For example, an administrator may be alerted via an email, a page, ete. 
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As shown in step 510, the logging service may periodically check for available storage space and may 
resume message logging if storage space becomes available. For example* a thread may periodically wake up to 
perform this check. Upon resuming message logging* the logging service may of course reserve storage ^ce for 
logging an out-of-storage-space condition again if necessaiy. 
5 As noted above* Figure 23 represents one embodiment of a method for handling out-of*5toiage-spaoe 

conditions, and various steps may be added, combined, altered, etc. For example, the logging service may be 
operable to check for declining storage space and may alert an administrator, e.g., via an email, before such a low 
level of storage space is reached that message logging suspension becomes necessaiy. As another exan^le, in one 
embodiment, the logging service may queue logging requests received from cliem processes in memory while 
10 message logging is suspended and may attenipt to log the messages cmce storage space becomes available. 

Although the embodiments above have been described in considerable detail, numerous variations and 
modifications will become apparent to those skilled in the art once the above disclosure is lully appreciated. It is 
intended that the following claims be interpreted to embrace all such variations and modifications. 
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L A method for enabling applicadoD server request faflover, the method con^rising: 
a requesting thread running in a client con^uter sending a request to an application server* wherein llie 
application server is operable to receive the request, process the request, and return request results to fht requesting 
thread; 

the requesting thread sleeping after said sending the request to the application server; 
the requesting thread waking up and sending a poll message to the application server, wherein the poU 
message con^riscs information identiiying the request, wherein the application server is operable to receive die 
poll message and respond by returning a status of the request to the requesting thread. 

2. The method of claim 1, further comprisiog: 

the requesting thread deteiniining whether a response to the poll message is received from the application 

servcTa 

3. The method of claim 2, further conqnising: 

the requesting thread receiving a response to the poU naessage from the application server; 
the requesting thread analyzing the response to detennine whether the application server is eurricntly 
prooesssing the request 

4. The method of claim 3, lurdier conqnisEog: 
■ the requesting thread returning to sleep if tfie app^cation server Is cuirenfly pmrr^sstt^ the req(ucat> 

5. The method of claim 3, further con^rising: 

25 the requesting thread re-sending the request to the application server if the application server is not 

currently processsing the request. 

6. The method of claim 2, wherein information regarding the current state of the appUcation server 
is maintained on the client computer, the method further comprising: 

30 the requesting thread determining that a response to the poll message is not received from the application, 

server; 

the requesting thread causing the client conqmtcr to update the information regardii^ the current state of 
the application server to reflect that the application server did not respond to the poU message. 

35 7. The method of claim 6, wherein the application server is a first application server in an 

application server dtister comprising the first application server and a second applicatira server, the m et hod fuitiier 
comprising: 

the requesting thread sending the request to the second application server. 
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8. The method of claim 6, fiinhcr comprising: 
the cUcnt computer periodically polling the application server; 

if the application server responds to said polling, the client computer updating the infonnation regarding 
the cunent state of the application server to reflect that the application server responded to said polling. 

9. The method of claim 6» 

wherein said updating the infonnation regarding the current state of the application server to reflect d»t 
the application server did not respond to the poU message results in the client computer not sending future requests 
to the application server. 

10. The method of claim 6, 

wherein said requcstiiig thread determining that a response to the poll message is not received from flic 
application server is accomplished by the requesting thread determining that a response to flie poll message is not 
received from the application server wifliin a certain period of time. 

11. Hie method of claim 1, 

^jitoein said sending a poU message to the application server compri^ 
(UDP) message io the application server. 

20 12. The method of claim 1, 

wherein said requesting thread waking up and sending a poD message to die appHcation server is 

performed periodically. 

13. The method of claim 1, 

25 wherein said requesting thread waking up and sending a pofl message to die application server is 

perforated periodically at time intervals specified by an administiator via a user interfile. 

14. The method of claim 1, 

wherein the request references a component running on the application server. 

30 

15. The method of claim 14, 

wherein the component is a component from die group consisting of: 

a JavaScrver Page con^nent, a Java Servlet component, an Enterprise JavaBeans coniponenL 

35 16. The method of claim 1, 

wherein the client conq;mter is a web server con^uter. 

17. A system comprising: 

a client computer including a CPU and memory; 

4g 
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a requesting thread stored in the memory of the client computer, wherein the requesting thread is operable 
to send a request to an application server computer; 

an application server computer including a CPU and memory, wherein the application server is operable to 
receive the request, process the request, and return request results to the requesting thread; 
a network connecting the client computer to the application server computer; 

wherein the requesting thread is execuuble to sleep after said sending the request to the api^cation scmx; 
wherein the requesting thread is executable to wake up and send a poU message to the application server, 
u4ierein the poll message comprises infoixnation identifying the request, wherein the application seivcr is operable 
to receive the poll message and respond by reniming a status of the request to the requesting thread. 

18. The system of claim 17, 

wherein the requesting thread is further execuuble to determine whether a response to Uie poll messa^ is 
received from the application sesvar. 

15 19. The system of claim 18, 

wherein the requesting thread is iiinhcr executable to receive a response to the poO message from die 
i^hcation server; 

wherein the requesting thread is frxrthcr executable to analyze the response to determine whether tfie 
application server is cimently processsing die request 

20 

20. The system of claim 19, 

wherein the requesting thread is further executable to retum to sleep if die applicatian server is cmrendy * 
processsing the request. 

25 21. The system of claim 19, 

wherein the requesting thread is further executable to re-send the request to the applicadoo server if die 
appUcation server is not currently processsing die request 

22. The system of claim 18, 
30 wherein the client con^utcr is operable to maintain information regarding die current state of the 

application server con^puter; 

wherein the requesting thread is further executable to determine that a response to the poll message is not 
received from the application server; ' 

wherein the requesting thread is further executable to cause the client conqniter to update die infonnatioa 
35 regarding the current state of the application server to reflect that the application server did not respond to the poll 
message. 
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23. The system of claim 22, wherein the application server com|»itci is a first application server 
coxi^uter in an application server cluster comprising the first application server computer and a second applicadoo 
server computer, 

wherein the requesting thread is further executable to send the request to the second application server 
5 computer. 

24. The system of claim 22. 

wherein die client con^ter is operable to periodically poll the application server computet; 
wherein, in response to receiving a response to the polling message fi^om the application server computer, 
10 the client computer is operable to update the information regarding the current state of dxc application server to 
reflect that the application server responded to said polling. 

25* The system of claim 22, 

wherein said' updating the information regarding die current state of the applicadoii server to reflect diat 
IS the application server did not respond to the poll message results in the client con^iuter not sending future requests 
to die q^lication server* 

26. The system of claim 22, 

wherein said requesting thread determining diat a response to the poll message is not received fiom the 
20 applicadon server is acccmqplished by the requesting dnead detenmning diat a response to die poO message is not 
received from the plication server widun a certain period of time. 

27. Thesystemof claim 17, 

wherein said sending a poll message to the application server conqirises sending a User Daitagram Protocol 
25 (UDP) message to die appfication server. 

28. The system of claim 17, 

wherein said requesting thread waking up and sending a poD message to the applicatiosi server is 
performed periodically. 

30 

29. Thesystemof claim 17, 

wherein said requesting thread waking up and sending a poO message to die plication server is 
performed periodically at time intervals specified by an administrator via a user interface. 

35 30. The system of daim 17, further comprising* 

an application conq>oneiit running on die applicadon server conqputer; 
wherein the request references die application conipcinrnt. 
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31. The system of claim 30, 

wherein the component is a component from the grottp consisting of: 

a JavaServer Page con^nent, a Java Servlet con^nent, an Entexprise JavaBeans componenL 

5 32. Hie system of claim 30p 

wherein the client computer is a web server computer. 

33. A memory medium con^>rising program instructions operable to bnplcmtB^ 

a requesting thread running in a client conqniter sending a request to an application server, wherein die 
10 application server is operable to receive the request, process the request, and return request results to the requestii^ 
dueadf 

the requesting thread sleeping after said sending the request to &e application s erve r , 
the requesting thread waking up and sending a poll message to the application server, wherein the poll 
message comprises information identifying the request^ wherein the application server is operable to receive dse 
15 poUmessageandiespondby returning a status of the request to die requesting thread. 

34. The memory medium of claim 33. further comprising program mstnictiuus operable to 
die requesting thread determining whedier a response to die poH message is received from the application 

20 scxvcr. 

35. The memory medium of claim 34. lurdier conqprising program instructions operable to 



the requesting thread recdving a response to die poll ixiessage from the application servci; 
25 the requesting thread analyzing the response to determine whether the applicatimi server is cuncDtity 

processsxDg the requcsL 

36. The memory medium of claim 35. iiirther cosq>rising program instructions operable to 
sr^plcnse^tt. 

30 die requesting thread returning to sleep ifdiea|>pUcation server is ctirrendypiocesssiiig die 

37. The memory medium of claim 35, further coxnprising program instructions operable to 
* T^^ ^^c^p*mtr 

die requesting thread re-sending die request to die application server if the application server is not 
35 currently processsing die request 

38. The memory mrdiimi of claim 34. wherein die client corr^juter is operable to ™t«tttw| 
information regarding the current state of the application server computer, the memory medium further conqnising 
program instructions operable to ooplement: 
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the requesdng tbread detennimng that a response to the poll message is not received from the application 

server; 

the requesting thread causing the client conq>uter to update the information regarding the current state of 
the.application server to reflect that the application server did not respond to the poll m ess ag e. 

39. The memory medium of claim 3 8, wherein the application server is a first application server in an 
application server cluster comprising die first application server and a second application server, the menxny 
jn y^iwTn further con^xrising program instructions operable to m^lemeot: 

the requesting thread sending the request to the second application server. 



40, The memoiy medium of claim 38, iuxther comprising program instructions operable to 
m^lementi 

the client conqniter periodicaOy polling the application saver; 

if the application server responds to said polling, the client computer updating the infonnation regarding 
15 the curxent state of the appHcation server to reflect diat the appbcation server responded to said polling. 

41. The memoiy medium of daim 38, 

^liieiein said updating the infonnation reganling the current state of the application server to reflect tint 
the application server did not respond to the poD message results in the client conputer not sending fliniie i 
20 to die application i 



42. Tlie memory mnditim of claim 38, 

^i^ierein said requesting thread determining diat a response to the poll message is not received from die 
application server is accomplisihed by die requesting diread determining diat a response to the poll message is not 
25 received from die application server within a certain period of time. 

43. The memory medium of claim 33, 

wherein said sending a poll message to die application server comprises sending a User Datagram Protocol 
(UDP) message to die application server. 

30 

44. The memory medium of claim 33, 

wherein said requesting diread waking up and sending a poll message to the application server ia 
performed periodically. 

35 45. The memory medium of claim 33, 

wherein said requesting thread waking and sending a poll message to the app] 
performed periodically at time intenrals specified by an administrator via a user intei&oe. 
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46. The memoiy medium of claim 33» 

wherein the request references a con^Kment running on the application server. 

47. The memory medium of claim 46» 

wherein the component is a component from the group consisting of: 

a JavaSeryer Page component, a Java Servlet component, an Enterprise JavaBeans con^mncnt 

48. The memory medium of claim 33, 
wherein the client computer is a web server conqmtcr. 
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